Nathan Sidwell <nat...@acm.org> writes:
> Here is the implementation of C++20 modules that I have been developing
> on the devel/c++-modules branch over the last few years.
Congrats on reaching this point.
> It is not a complete implementation. The major missing pieces are:
>
> [...]
Building C++20 modules requires non-trivial integration between the
compiler and the build system. This patch set introduces a module
mapper, a novel mechanism for such integration. Has it been tried
by any non-toy build system and on any real project?
If the answer is "no", then by shipping modules in GCC 11 are we
making any likely changes in this area impossible or unnecessarily
difficult?
To give an example of such a likely change, currently the mapper
has a notion of the central module repository directory that is
used to resolve all the relative CMI (compiled module interface[1])
paths (even paths like ./foo.gcm). However, this model will not
apply to all build systems. For example, in build2 (the build
system I am involved with), there can be no such central place
since a project can pull dependencies that are built in other
places. Currently, the only way to disable this repository
semantics is to use absolute CMI paths throughout.
Also, FWIW, I've attempted such a build system integration with
build2 back in 2019. While the overall idea of the module mapper
worked well, I had to make substantial extensions in my own
branch[2] of Nathan's c++-modules (also described in this[3]
WG21 paper). AFAIK, these extensions haven't yet been considered
for merging into c++-modules.
[1] BTW, SG15 seems to have settled on the BMI (built module
interface) term instead of CMI:
https://github.com/cplusplus/modules-ecosystem-tr/blob/master/definitions.tex
[2] https://github.com/boris-kolpackov/gcc-cxx-modules-ex
The branch used to live on gcc.gnu.org/git but was dropped as
part of the svn-to-git migration.
[3] https://wg21.link/P1842
