[cfe-dev] [RFC] C++20 modules dependency discovery

[Ben Boeckel via cfe-dev]

On Tue, Aug 13, 2019 at 13:49:47 -0700, Michael Spencer wrote:
> On Tue, Aug 13, 2019 at 1:33 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:
> > I avoided the `-M` flag family because that means "make". This is not
> > make syntax, so it doesn't belong there. In addition, the existing `-M`
> > flags are still useful because the "should I rerun this rule" logic for
> > the scan step itself can be satisfied with the `-M` flags here.
> 
> This is not something I had considered.  I agree it's highly useful to be
> able to not rescan if nothing changed.  It's also important that clang uses
> the same flags as gcc here, have you heard from the GCC devs on your GCC
> patch?

Nathan wants to wait for the TR before merging it to his branch. I can
send the patch as an RFC to the GCC list I suppose. Should I CC you?

> > Sounds reasonable. Matching GCC's output for them might be a viable
> > option, but that is going to make not-make parsers of the `.d` files
> > choke (since that output involves appending to make variables).
> 
> What output do you do for GCC?

If modules are enabled and `-fdep-format=` is specified, it is basically
just a list of paths read because of `#include` directives.

> > This sounds like what a Meson developer is expecting in this blog post:
> >
> > https://nibblestew.blogspot.com/2019/08/building-c-modules-take-n1.html
> 
> It seems similar, but the intent isn't really for "real" builds.  It's just
> to support simple cases so that step one of using C++ isn't setting up a
> build system.

I'm aware that it would really be a simplified build model compared to
what is possible today. Discussion on Reddit was a little heated if
you're interested, but I feel like we were mostly talking on different
levels (me wanting to support what is possible with the IS, others just
wanting to support some idealized C++ build model):

    https://www.reddit.com/r/cpp/comments/cn6osf/building_c_modules_take_n1/

I don't think the "just have the compiler do the hard part" is viable
because module deps between targets still need wired up and doing things
naively means your builds end up being more entangled than one really
wants it to be. But, other build systems can choose the easier problem
than CMake ends up solving. I just don't think expecting compilers to do
all the heavy lifting with module deps is a viable solution for the
wider C++ community.

> > > The other issue with -MD is that I believe tools that use `.d`
> > > files wouldn't even be able to handle a `.d` that included actual
> > > commands.
> >
> > Correct. Ninja tries to handle the barest of syntax for these files
> > (basically what is seen in the wild).
> 
> This makes me think we really shouldn't even try to do that then.

Agreed.

--Ben