On Fri, Feb 08, 2019 at 22:17:10 -0800, Bruno Cardoso Lopes wrote:
> 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.

One problem here is knowing how to build that dependency. The bigger one
is that you also don't really want to write files out the build tool
doesn't know about (that can affect the build graph) because they may
have the command generating that output already scheduled. Plus, build
tools can optimize better if they know more about the graph.

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

Note the only real issue is getting the compile order correct. I expect
tutorials forgoing full-blown build tools to either just have the
commands in order already or they're small enough that manual dependency
listing isn't a huge burden. It does need notes that "playing around"
can make the build fail due to ordering issues though.

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

I think it fits more with scan. Collate is more build-tool aware and has
to write specific formats (make, ninja, dot, ant.xml, whatever the build
tool consumes) that can be loaded during the build. A scan tool already
has enough problems gathering the information in the first place.

--Ben