- User Since
- Jul 3 2017, 9:16 PM (115 w, 2 d)
Dec 28 2017
I don't think it will be wise for me to accept this revision since I can't claim to have good understanding of Clang's internal modules model. I think it will be wise to have Richard take a look.
Nov 24 2017
LGTM. Maybe it makes sense to also test that an unrelated translation unit that imports module 'test' sees neither 'a' nor 'b'.
Nov 22 2017
All our tests pass as well. Thanks for your work!
Nov 20 2017
LGTM. Will be happy to also run our re-export tests in build2 once this is merged.
Nov 17 2017
Also, to add to my previous comment, even if for a moment we ignore the header dependencies and when they are extracted, a modern build system normally tracks other kinds of what can be called "auxiliary dependency information": some form of compiler signature, hash of options that were used to compile the file, etc., so that when any of those change, the object file gets recompiled automatically. For example, in build2, we store all these signatures/hashes plus the header and module dependency information in a single .d file (which we call auxiliary dependency database). What I am trying to show by this is that it is well established that for C/C++ compilation there has to be an extra file for each .o where such information is stored. And it seems natural to want to reuse this file for supplying the "module map" to the compiler instead of creating yet another per-.o file.
Nov 4 2017
Nov 3 2017
Oct 27 2017
Oct 20 2017
Oct 13 2017
Oct 9 2017
Sep 29 2017
Sep 25 2017
Another attempt to upload a clean diff (also rebased on latest HEAD).
Yes, the main "feature" of this approach compared to @file is the ability to reuse an already existing file to store this information. Most build systems that support C/C++ compilation have to store auxiliary dependency information at least for the extracted header dependencies (those .d files generated by the -M option family, for example) but some also store hashes of options, compiler version/signature, etc. So instead of creating a yet another file (per translation unit), the idea is to reuse the already existing one by storing the mapping with some "distinguishing" prefix. As a concrete example, a make-based build system could append it to the .d file (which is a makefile fragment) as comments. How exactly this information is extracted is still an open question but I think this approach is generic enough to accommodate a wide range of possibilities (for example, -M could produce this information or the build system could append it itself after the -M is done).
New revision this time with the tests (which got dropped from the earlier revision diff for some reason).
Sep 15 2017
Sep 8 2017
Sep 4 2017
New patch revision with David's comments addressed.
David, thanks for the review. Uploading the new revision (also rebased on HEAD).
Aug 30 2017
Aug 24 2017
Aug 19 2017
New revision of the patch that I believe addresses all the issues except for the '=' escaping.
I've marked as "done" items that I have resolved in my local revision (not yet uploaded) and have added one comment for further feedback.
Aug 16 2017
Aug 13 2017
Richard, sorry for the last ping, somehow I missed your review.
Aug 9 2017
Aug 3 2017
Aug 1 2017
Jul 26 2017
Jul 25 2017
FWIW, I went ahead and implemented this functionality in GCC. It has been merged into its c++-modules branch.
Jul 20 2017
Jul 17 2017
I am holding off on proposing the same functionality to GCC because I want to make sure the command line interface is the same for both compilers (GCC has less baggage in this area, option-name-wise). So confirming that at least the naming/semantics are acceptable would be very helpful.
Rebase on latest HEAD.
Jul 11 2017
Rebase on latest HEAD.