On Sat, Mar 01, 2025 at 20:01:21 +0000, vspefs wrote:
> Supporting C++ modules is easy, but I don't think "properly" is possible for
> any
> build system under current circumstances. Industrial consensus needed for many
> subjects:
I believe CMake is the furthest in this regard (though I haven't looked
at what xmake does between projects), but it currently only offers the
information through CMake target properties which is not all that useful
outside of CMake itself. The likely solution is to use CPS:
https://github.com/cps-org/cps
to propagate the information in a more tool-agnostic way.
> For example, the "permission to import" thing of module is also a general
> distribution issue. We are still not clear about how we should distribute
> modules, with questions like:
I encourage you to join the Ecosystem Evolution group where these things
are being discussed:
https://groups.google.com/g/cxx-ecosystem-evolution/about
There's also the #ecosystem_evolution channel on cpplang.slack.com if
you're interested.
> 1. Is there a system-wide, universal way of finding installed modules?
I don't believe there should be a way to just "find" modules as they
have done so for headers. Modules may require their own `-D` flag
settings (e.g., export macros for shared vs. static usage) and have
their own dependencies. Just finding files on disk offers none of that.
> 2. How much information should we expose when distributing a module? In what
> way?
What CMake exports is a minimum, but there may be more. Beyond normal
CMake target things like flags and dependent targets, for C++ modules
there is:
- the list of module interface files part of the target
- a list containing tuples of the form:
- module name
- module interface unit
- list of installed CMIs available (currently unused; really needs
something like
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2581r0.pdf
to reliably use.
Right now CMake exports this as CMake properties, but encoding it in CPS
is something we'll need to figure out down the line.
> GCC and clang both have a .module.json file installed under /lib path, which
> kind of attempt to answer the first question, and reply the second question
> with
> "look, here we try to have a structured description of distributed modules".
MSVC has one too; the formats differ slightly, but they're pretty close.
Again, something for the Ecosystem Evolution group to work on. GCC and
Clang are using the format discussed here:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3286r0.pdf
> They're obviously very early, immature, and underdeveloped attempts that
> aren't designed to solve this problem anyway. But a well-designed "structured
> description of distributed modules" can solve a lot of problems. However, the
> question could grow bigger when you throw in more ideas like versioning.
>
> We don't necessarily need to have the answers standardized, but some form of
> consensus needs to exist.
>
> Another example is the "multiple CMIs" question. From one aspect, if C++
> standard could officially define/validate/standardize compile options, it
> would be much easier to have a making-everyone-happy answer to this.
> (although it's simply offloading the annoying-everyone part to the committee)
>
> I know some SG15 attempts (like P3335), but you never know standardization.
ISO is a…complicated beast with its rules that make it difficult to have
public official documents, so Ecosystem Evolution is the place to be.
> I made this RFC to see if we can have a usable `-Mmodules` output now, and if
> we can design it so well that it could be trivially useful when build systems
> implement module-supported Makefile generation. Also to see where we should
> draw
> the line between "build system scope" and "compiler scope".
I'm not sure how useful one-compiler-one-tool solutions are. The issue I
see is that the build *system* needs to be involved to translate what
"this TU creates a CMI file" *means* in the context of its semantics.
Basically, P1689 is the mechanism by which build systems can implement
their policies. I don't know what kind of useful policy is possible from
the compiler's point of view without imposing some level of "this TU is
part of a group X which participates in a larger semantic usage graph
not visible purely from the Makefile recipes".
> > Clang does support separate `.cc -> .pcm` and `.pcm -> .o` commands,
> >
> > but, IIRC, this is not actually equivalent to `.cc -> {.pcm, .o}` in
> >
> > that the codegen may differ subtle ways that may matter. I'm interested
> > in correctness before we start really squeezing performance out of the
> > setup, so I'd like to avoid adding more bumpy roads along the way before
> > we have a smoothed out path to compare it against if/when bugs crop up.
>
> I totally agree. My opinion is that it's easier to change compiler
> implementations/behaviours than established building practices, so we must try
> to make sure we get the latter right.
I think there is work to be done to facilitate at least `import std;`
working from a single `g++ byhand.cc` command, but anything beyond that
is likely in "need a build system" territory due to having higher-level
semantics. That's not to say that there can't be something like:
myfavoritebuildsystem --quick --use=boost@1.80 --as-shared-library=mylib
--sources mylib.cc
to do such "one shot" compilation behind the scenes.
Thanks,
--Ben
