<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 13, 2018 at 4:41 AM Whisperity <<a href="mailto:whisperity@gmail.com">whisperity@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I have now delved a bit into the Modules TS implementation from a<br>
user standpoint (due to having implemented support for it in CMake,<br>
see the patch here:<br>
<a href="https://gitlab.kitware.com/cmake/cmake/merge_requests/2482" rel="noreferrer" target="_blank">https://gitlab.kitware.com/cmake/cmake/merge_requests/2482</a> )<br>
(Some of these concerns are already voiced by Boris in<br>
<a href="https://build2.org/article/cxx-modules-misconceptions.xhtml#build" rel="noreferrer" target="_blank">https://build2.org/article/cxx-modules-misconceptions.xhtml#build</a> )<br>
<br>
 1. The first big issue is that while the "C++98 Modules" is somewhat<br>
well-documented, the "Modules TS" has absolutely no workable<br>
documentation available at all... I had to resort to looking up<br>
Clang's option td files to figure out what this thing is supposed to<br>
do.<br></blockquote><div><br></div><div>Fair cop - work in progress, etc. Though it's far enough along it could probably use some documentation even if it said clearly "this is in flux, may be out of date, etc".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 2. Currently, Clang is wonky on how modules can be found. You need to<br>
explicitly specify the modules' location which (the prebuilt, if you<br>
want to allow caching of PCMs and no re-read of CPPM files all the<br>
time...) has to be a single folder.</blockquote><div><br>What command line are you referring to here? -fmodule-cache-path?<br><br>That's more used around the "implicit modules" support, which isn't likely to be supported/useful for ModulesTS style modules (becaues you'll want, maybe need, to build object files from the module files - so your build system would need to be aware of building module files).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The PCM must be available prior to<br>
compilation so the main file is semantically correct, but *it also has<br>
to be linked* against the resulting binary, otherwise implementations<br>
will provide linker errors. (If I link .o instead of .pcm, it will<br>
still work, and .o files are smaller than PCMs, but compilation will<br>
have to semantically analyse the CPPM file providing no speedup on<br>
module contents.) There is no direct sanity check that I'm linking the<br>
same PCM that I used for compiling, and it looks like the PCM must be<br>
linked *explicitly* (so the '-fprebuilt-modules-path' doesn't work<br>
here.)<br></blockquote><div><br>yep, the build model currently is entirely explicit, something like this<br><div><br></div><div>COMMON_FLAGS="-cc1 -xc++ -emit-module -fmodules -w"</div><div>CLANG=clang<br></div><div>$CLANG $COMMON_FLAGS -fmodule-name=foo foo.cppmap -o foo.pcm -fmodules-codegen</div><div>$CLANG $COMMON_FLAGS -fmodule-name=bar bar.cppmap -o bar.pcm -fmodules-codegen -fmodule-file=foo.pcm</div><div>$CLANG -c foo.pcm</div><div>$CLANG -c bar.pcm</div><div>$CLANG -cc1 -emit-obj -fmodules -fmodule-file=foo.pcm -fmodule-file=bar.pcm use.cpp</div><div>$CLANG foo.o bar.o use.o<br><br>Basically - build the .pcms, use those pcms to build object files for the pcms, and use the pcms to help build the object file for the user, then link all the objects together as usual.<br><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">3. This might be very CMake specific or I only found this issue<br>
because working on CMake recently, but it is a real pain the behind to<br>
figure out on which modules a translation unit depends. Unlike '-M'<br>
which nicely spits out imports, the only option I saw so far is to<br>
grep for the import statements and then try to map these to the module<br>
files under the prebuild folder. (This is one of the issues I just<br>
didn't succeed (perhaps yet?) in CMake because CMake is also<br>
*somewhat* wonky, at dependency check time it does not know about<br>
other targets and configuration, so I just can't implictly and<br>
automatically say "Okay now please depend on<br>
./whatever/path/mymodule.pcm or it's corresponding cppm input...)<br>
I think this eventually needs to be considered because -M respects<br>
compiler options when resolving the headers, so I think it's logical<br>
that -M (or "-fmodules-list-dependencies" or whatever...) could also<br>
respect where the prebuild dir is and spit out the PCM paths (or even<br>
better the original CPPMs' -- I think PCM contains a backwards link to<br>
where it was built from?) the TU depends on.<br></blockquote><div><br>Yep, build integration with modules is still very much uncertain/unknown. Experiments/ideas/prototypes are all being played with - but more experiments/design suggestions are welcome.<br><br>GCC is prototyping a "callback" system of sorts - when the compiler needs a BMI (binary module interface - Clang's are the .pcm files) it would callback into the build system to ask for the file path of the BMI (so the build system could go off and build it, then inform the compiler where it is).<br><br>Clang requires it all explicit at the moment, as I showed above - the build system could either have its own import/inclusion discovery or maybe -M could be expanded to support imports, etc.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Whisperity.<br>
David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> ezt írta (időpont:<br>
2018. okt. 4., Cs, 20:02):<br>
><br>
> Yeah, Richard seems to be working on modules TS features when he has time amongst other priorities.<br>
><br>
> Any particular areas you've found gaps you've been interested in filling?<br>
><br>
> On Sat, Sep 29, 2018 at 8:15 AM Matt Asplund (mwasplund) via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>><br>
>> Hello,<br>
>><br>
>> I am curious if there is any active work being done on the Modules TS implementation. I would like to help fill in the gaps that I am finding while playing around with it and wanted to make sure I wasn’t duplicating work.<br>
>><br>
>> -Matt<br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>