[cmake-developers] Experiments in CMake support for Clang (header & standard) modules

David Blaikie dblaikie at gmail.com
Tue Aug 7 20:29:03 EDT 2018


On Mon, Aug 6, 2018 at 2:37 PM Stephen Kelly <steveire at gmail.com> wrote:

> Stephen Kelly wrote:
> >> The build.sh script shows the commands required to build it (though I
> >> haven't checked the exact fmodule-file dependencies to check that
> they're
> >> all necessary, etc) - and with current Clang top-of-tree it does build
> >> and run the example dinnerparty program.
> >
> > Ok. I tried with my several-weeks-old checkout and it failed on the first
> > command with -modules-ts in it (for AbstractFruit.cppm - the simplest
> > one).
> >
> > I'll update my build and try again, but that will take some time.
>
> I have locally tried your modifications. Aside from the content of my
> previous email, I updated my clone (force push) to clean up the commits,
> and
> to modify your build.sh script to maintain the different libraries in the
> repo.
>
>  https://github.com/steveire/ModulesExperiments/commits/master
>
> I am still interested in what the C++ code (and build.sh) look like in the
> case of one-module-per-library.
>

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.


> It is obvious from looking at build.sh as it is that the buildsystem needs
> to be changed when adding a new import to a c++ file, as I have described.
>

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.

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)

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)

(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... )


> see the commit adding Grape separately and the changes required to the
> buildsystem which were not required in the non-modules world:
>
>  https://github.com/steveire/ModulesExperiments/commit/428bea53fc6
>
> I will see if I can get a recent GCC build for comparison and to determine
> whether the callback-to-the-buildsystem used in GCC makes a difference in
> that respect.
>
> I'm still interested in a response to my previous email in that respect.
>

Yep, coming back to that now.


>
> Thanks,
>
> Stephen.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20180807/c31ec55b/attachment.html>


More information about the cmake-developers mailing list