On Mon, Jul 25, 2022 at 19:48:28 +1000, Zopolis0 via Gcc wrote:
> Currently, when importing the standard library, one has to
> separately compile each unit they want to use, which is a hindrance to the
> build process and a gap in the implementation.
>
> Is there any particular reason why gcc doesn't provide importable header
> units for the standard library? Is there a timeline for this? Given that
> the standard library can already be compiled into header units, is there
> any particular reason why those aren't shipped with gcc?
Some questions that come to mind if GCC were to provide this:
- What flags should be used for these pre-compiled units?
- How do you expect build systems to be able to find them? Will there be
some kind of naming convention? It'd certainly be nice if other
implementations would cooperate…
(FD: CMake developer working on module support myself) It is my belief
that any module-supporting build system has to consider the possibility
of compiling any given external module because there's no guarantee that
the flag set is compatible (say, `-ffast-math` or other "fun" flags with
ABI implications) and you'll need your own compilation of the module
anyways. Having pre-compiled units is nice, but merely an optimization
for any robust build system; you certainly can't just use any available
pre-compiled module blindly (unless you're relying on the linker to
detect mismatches or something).
The C++ committee's SG15 (Tooling) is looking into the problem. These
papers are likely of interest to you (still under discussion):
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2577r2.pdf
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2581r0.pdf
More papers will certainly appear:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/
--Ben
