<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 6, 2018 at 2:37 PM Stephen Kelly <<a href="mailto:steveire@gmail.com">steveire@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Stephen Kelly wrote:<br>
>> The build.sh script shows the commands required to build it (though I<br>
>> haven't checked the exact fmodule-file dependencies to check that they're<br>
>> all necessary, etc) - and with current Clang top-of-tree it does build<br>
>> and run the example dinnerparty program.<br>
> <br>
> Ok. I tried with my several-weeks-old checkout and it failed on the first<br>
> command with -modules-ts in it (for AbstractFruit.cppm - the simplest<br>
> one).<br>
> <br>
> I'll update my build and try again, but that will take some time.<br>
<br>
I have locally tried your modifications. Aside from the content of my <br>
previous email, I updated my clone (force push) to clean up the commits, and <br>
to modify your build.sh script to maintain the different libraries in the <br>
repo.<br>
<br>
 <a href="https://github.com/steveire/ModulesExperiments/commits/master" rel="noreferrer" target="_blank">https://github.com/steveire/ModulesExperiments/commits/master</a><br>
<br>
I am still interested in what the C++ code (and build.sh) look like in the <br>
case of one-module-per-library. <br></blockquote><div><br>Oh, sure - that's easy enough, in terms of rolling together any modules in the same library. Mash all the code in any cppm interface files that are part of the same library into a single cppm file & build that into a single module.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is obvious from looking at build.sh as it is that the buildsystem needs <br>
to be changed when adding a new import to a c++ file, as I have described. <br></blockquote><div><br>Though potentially not manually - and some of those lines would be added when the new module was added (as would be done when a new .cpp file is added today) - rather than when the import occurred.<br><br>The 'worst' part is for intra-library module dependencies. For inter-library module dependencies, a coarse-grained solution would be to only build a library once all of the BMIs (.pcm files) for dependent libraries are built - and all of those are passed to libraries that depend on them. But, yeah, having the build system trying to figure out the dependency between modules within a library (which isn't explicit in the build files, unlike the inter-module dependency) is awkward. (& honestly, for maximum build parallelism, you wouldn't want the coarse-grained solution I described above - because then if something in library A depended on only module B.1 but not module B.2, you'd want to start building that part of A when B.1's BMI was built, without waiting for B.2's BMI to be finished)<br><br>So, yes, if you have more than one module per library, then both for the intra-library module dependency problem and the minimal-cross-library dependency issue, you'd need the build system to either be told by the compiler as its going (ala the proposed build server/oracle system that's implemented in GCC) or by pre-scanning with a semi-aware scanner (doesn't have to know all of C++ - modules are notionally well defined to be able to scan a short preamble with limited syntax... but I'm not fully up on all the nuance there & retro #include-to-import legacy support might complicate things)<br><br>(I guess, technically, even in the one-module-per-library, arguably your library dependency courld be a purely implementation dependency, in which case you'd still want to be able to build your 'dependent' BMI without waiting for the dependency's BMI to finish, since they don't depend on each other - so if your build system doesn't differentiate between external and internal dependencies, then again you'd need the kind of discovery phase if you want maximal build parallelism... )<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
see the commit adding Grape separately and the changes required to the <br>
buildsystem which were not required in the non-modules world:<br>
<br>
 <a href="https://github.com/steveire/ModulesExperiments/commit/428bea53fc6" rel="noreferrer" target="_blank">https://github.com/steveire/ModulesExperiments/commit/428bea53fc6</a><br>
<br>
I will see if I can get a recent GCC build for comparison and to determine <br>
whether the callback-to-the-buildsystem used in GCC makes a difference in <br>
that respect.<br>
<br>
I'm still interested in a response to my previous email in that respect.<br></blockquote><div><br>Yep, coming back to that now.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Stephen.<br>
<br>
<br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake-developers</a><br>
</blockquote></div></div>