On Tue, May 11, 2021, at 12:15, Ben Boeckel via SG15 wrote:
> Hi,
>
> After discussing with some implementers about real-world usage of the r3
> format. In these discussions the following things have been considered:
>
> # Dropping the `inputs`, `outputs`, and `depends` arrays
>
> These fields are intended to capture the dependency information of the
> scanning step itself. The intended replacement is the normal dependency
> mechanisms offered by compilers (be it `/showIncludes`, `-M`, or other
> possible mechanisms). These are really only of use to the build tool
> itself to know when to recompile the file, so putting it into the file
> format itself is unnecessary.


I'm very much against relying on 'existing' mechanisms as none of them are uniform between implementations, nor even between locale implementations. I would be fine with having multiple formats, or even spinning these arrays out into their own file, but a uniform format for these is desperately needed, especially in multi-language repositories where C++ code might be wrapped for use in something like Node, Ruby, Python, etc. C++ needs to be usable outside of a purely C++ environment, and making other languages struggle when they can just call `cargo build` or even just `rustc <entrypoint-file>` instead is going to be a detriment.

> In addition, there are two other reasons that have come up to at least
> consider changing these keys:
>
> - the `depends` array may be large: removing it means that tools which
> are just looking for `future-compile` information do not need to
> parse and throw away these fields
> - it does not match the semantics in batch scanning: what is really
> wanted here is a top-level `inputs`, `outputs`, and `depends` set of
> keys because the batch scanning step itself has just one set of
> this information.
>
> Since compilers, build tools, etc. already have mechanisms for
> communicating this information around, reusing those rather than
> injecting them into the format is likely a better solution.
>
> # Moving `future-compile` keys up one level
>
> Now that the other keys here are gone with the prior point
> (`future-link` was dropped in r1 due to its dubious usefulness[1]),
> `future-compile`'s keys `outputs`, `provides`, and `requires` keys can
> be moved up one level.
>
> # Clarification of header unit representations
>
> C++ has a difference between header units and module units. However,
> this is a C++-ism and the format would be useful to use in other
> languages as well (namely Fortran) where such a dichotomy does not
> exist. As such, formalizing the use of `<>` and `""` wrapping in the
> `logical-name` key should be noted for use for C++. Due to the multiple
> ways of spelling various includes (e.g., `"boost/version.hpp"`,
> `<boost/version.hpp>` or even `<Boost/Version.hpp>` on case-insensitive
> filesystems), the `source-path` should be used for linking such uses
> together instead.
>
> To do this, the `logical-name` should be the in-source name (for use in
> module mapper or other such mechanisms for finding the BMI for a given
> module by its name), `source-path` must be provided for header units.
> I don't think specifying `<>` and `""` in the format itself is the
> greatest, so an additional bool key named `unique-on-source-path` (open
> to bikeshedding) would indicate that the `source-path` should be used
> for linking between `provide` and `requires` lookups.
>
> Thoughts?

I'm not too keen on the use of `<>` and `""` in the format itself either. It would be fine if we kept "boost/version.hpp" as not having to escape quotes. I'd be ok with the use of some optional boolean key to indicate that it was written as `<boost/version.hpp>`, but we shouldn't have to worry about properly escaping or roundtripping includes between JSON and... literally anything else.

> --Ben
>
> [1] The only usecase that we could come up with was MSVC's
> `#pragma(comment)` for "autolinking".
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden] <mailto:SG15%40lists.isocpp.org>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>