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

[Bruno Cardoso Lopes via cfe-dev]

On Tue, Aug 13, 2019 at 2:02 PM Ben Boeckel via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> 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.

Probably won't scale but it has an educational value, and seems to be
in scope for implementations (including clang) to be able to do it
(not really sure about how much viable).

If we had a mode like `$ clang++ -std=c++20 a.cpp b.cpp c.cpp a.cppm
-o program`, we could still add something like `-fdep-mode=transitive`
and get the additional output we would get when dep scanning. Such
output would be useful to at least bulletproof an implicit modules
implementation by replaying it using a build system.

>
> > > > 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc