Subject: Scandeps format post-P1689R3 discussion
From: Ben Boeckel (ben.boeckel_at_[hidden])
Date: 2021-05-11 14:15:51
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.
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
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),
`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
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.
 The only usecase that we could come up with was MSVC's
`#pragma(comment)` for "autolinking".
SG15 list run by email@example.com