On Fri, Feb 08, 2019 at 13:34:43 -0800, JF Bastien wrote:
> Let us know if you have any feedback!

§2
> It is no slower to determine the dependencies of a modular C++ file
> than a normal C++ file today, and current proposals aimed at
> restricting the preamble wouldn’t make a scanner any faster.

Header dependencies are subtly, but crucially, different than module
dependencies. One can determine header dependencies *while compiling*
the file (though is not necessarily how it is implemented) and can be
done at any time once the source file is up-to-date. The first run does
not need this information because we already know we need to run the
output; storing discovered dependency information is a nice side effect.

Module dependencies must be present *during compile*, so must be
determined at build time (since source files may not be available before
the build has started) *before* compilation starts.

§2.2
> <clang-scan-deps>

Assuming there is consensus on D1483§7, I think this tool can be worked
to satisfy it. There may be issues around having the tool emulate other
compilers, but we have experience with that as well[1]. I think we may
even be able to drop some features from the list (e.g., pcm generation
at scan time and "installed listeners") in your paper.

§2.3
> <mapping files>

The approach we describe doesn't require mapping files at all. Other
tools may find them useful however. I'm thinking mainly static analysis
tools (versus those that piggyback on the compiler like IWYU and
`clang-tidy`) since they can't just say "run us with your build tool".

§2.4
> We believe modules should be built (not shipped or distributed) as
> part of a build, and potentially shared in the same environment for
> other compiler invocations that end up using non-conflicting setups.

Linux distros aren't going to like this… Nor are ports-based systems
(like Homebrew). Go, Rust, and other languages can get away with it
because given source code, how to build it is dictated by convention and
available tooling. C++ is a wild west of solutions for the "source ->
binary" transformation and given a set of sources, there's no "good way"
to just know how to compile it today.

That said, I don't think it's something the language standard can
dictate, but compilers can work together to provide something shippable
beside compiled libraries.

Thanks,

--Ben

[1]https://github.com/CastXML/CastXML