<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 15, 2018 at 10:12 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">In my previous post I have talked about the Modules >>TS<< system.<br>
I've also mentioned "-fprebuilt-modules-path" and also earlier on I<br>
think I've also mentioned "TS". I think the whole modulemap thing will<br>
always be a legacy or a compiler-specific extension, simply because<br>
every effort towards improving Modules TS and eventually getting it<br>
into the real standard does not consider this whole "module map"<br>
thing.<br></blockquote><div><br>True, though the standard doesn't talk about a lot of things (like header search paths) that implementations take for granted these days.<br><br>Specifically I think module maps will be part of things for standard legacy modules. Currently my understanding is that legacy modules would be discoverable only by their use as the target of a legacy import - so in theory a compiler/build system could discover and classify headers as such that way, but it's probably not super practical that way (in part because then there'd be lots of duplication for all the parsing of any header that wasn't a target of a legacy module import - but only used indirectly by legacy modules).<br><br>So I think there might still be some room/motivation for modulemap style support.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With this in mind, maybe the best course of action is to improve upon<br>
the "Modules TS"(-ish) implementation and get more results out of it<br>
and hit more roadblock to get data on which the eventual "real deal"<br>
is improved with.<br>
<br>
Unfortunately, my CMake patch was rejected (or put on hold?) today<br>
because the whole Modules TS thing still being rather new, never<br>
standardised, compiler developers arguing about the internals (just<br>
see this current thread ;) )<br></blockquote><div><br></div><div>Yeah, perhaps the best that can be done is to come up with prototypes to help inform both the standards effort and the cmake direction when it comes to that.<br><br>That said, maybe the fact that modulemaps are already a validated implementation in clang might be a gateway for adding cmake support for that, a shipping/in-use feature. Certainly Clang/LLVM could benefit from being built with that sort of mode (& many other C++ code bases could opt into this).<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> ezt írta (időpont: 2018. okt. 15., H, 17:30):<br>
><br>
><br>
><br>
> On Sat, Oct 13, 2018 at 4:41 AM Whisperity <<a href="mailto:whisperity@gmail.com" target="_blank">whisperity@gmail.com</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
> 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".<br>
><br>
>><br>
>>  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.<br>
><br>
><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>
><br>
>><br>
>> 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>
><br>
><br>
> yep, the build model currently is entirely explicit, something like this<br>
><br>
> COMMON_FLAGS="-cc1 -xc++ -emit-module -fmodules -w"<br>
> CLANG=clang<br>
> $CLANG $COMMON_FLAGS -fmodule-name=foo foo.cppmap -o foo.pcm -fmodules-codegen<br>
> $CLANG $COMMON_FLAGS -fmodule-name=bar bar.cppmap -o bar.pcm -fmodules-codegen -fmodule-file=foo.pcm<br>
> $CLANG -c foo.pcm<br>
> $CLANG -c bar.pcm<br>
> $CLANG -cc1 -emit-obj -fmodules -fmodule-file=foo.pcm -fmodule-file=bar.pcm use.cpp<br>
> $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>
>> 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>
><br>
><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>
><br>
>><br>
>><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>