> On Feb 8, 2019, at 13:59, Ben Boeckel <ben.boeckel_at_[hidden]> wrote:
>
> 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.

One can also determine modules dependencies *while compiling* if the implementation lazily build the dependencies. Might not seem the best idea to embed a mini build system inside the compiler, but the kraken could end up speeding builds on a number of cases, like with "implicit" clang modules. I believe an "explicit" model will be the best way to make things scale, but a "implicit" model has also potential advantages since its easier to teach and lowers the bar for beginners to try C++ Modules without any specific build system knowledge. It's a good thing that implementors are free to try all of these options!

>
> §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].

That would be great. I don't see a reason not to have more of this in clang or in clang based tools.

> 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.

I'm sure there will be a lot of room for improvements.

>
> §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".

I find your approach very promising, looking forward to see it happen. More specifically, I could see clang-scan-deps one day being a fit for either scan or collate phases.

>
> §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
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling