cxx20 module support for gcc #4248
Conversation
|
GCC general documentation on modules: |
|
Since there are some other links in the long-running discussion, plus notes on how clang does things, thought I'd mention the Bazel project's issue bazelbuild/bazel#4005 |
Add variables to enable and controll gcc module support. So far only manual module map specification is supported and proper dependencies on module files are not established.
This is done in emitter so won't work for generated files
so it could be potentially used to run commands outside scons as a mapper file.
loonycyborg
force-pushed
the
cxx20-gcc
branch
from
974201d
to
b5f8a00
Compare
|
Hey how's this commit going? Any one still following up? |
|
Any contributions here welcome. We perhaps should have a better place for "discussion" about the right design for this (the one in the PR may in fact be that). In the meantime, this link can be a partial starting point, since it describes a problem and has more links: https://github.com/urnathan/libcody There's a newer version of 1184: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1184r2.pdf Not sure if the mapper/build communication stuff is overkill for a first cut at supporting modules. As I said - maybe a separate location for discussion? |
|
Good to know. But sorry I'm kind of confused by now. Cuz I saw this commit in bazel's issues. But it seems that this is another repo. I'm wondering what's the relationship between these two? |
|
relationship? just a problem that all the build systems have to solve, in the face of a not really unified compiler approach to tackling it. |
|
We have a channel for this on Discord. |
C++ module support
This PR is aimed is aimed at adding support for C++20 modules for gcc, perhaps also adding infrastructure that could be reused by clang/msvc. Intended interface is to enable module support only if CXXMODULEPATH is set to non-empty path and store module files there.
Contributor Checklist:
CHANGES.txt(and read theREADME.rst)