Importable STL Header Units?

Importable STL Header Units?

[Zopolis0]

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?

Re: Importable STL Header Units?

[Ben Boeckel]

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

Re: Importable STL Header Units?

[Jonathan Wakely]

On Mon, 25 Jul 2022 at 10:49, Zopolis0 via Gcc <gcc@gcc.gnu.org> 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?

Are you asking why GCC doesn't install compiled module interface files
for the std::lib headers? Those would have to be built with a specific
set of compiler options, and then would only work if you compile with
those same options. Should they enable C++20 features, or C++23 as
well? Should they be built with assertions enabled? etc. etc.

Those seem like things that should be decided by the user consuming
those header units, not by the GCC project.

More generally, GCC's support for modules (and all of C++20) is still
experimental, so I don't think we're ready to be installing CMI files
yet. If you disagree, feel free to propose patches to install header
units. Changes like that happen because somebody works on it, not by
magic.

Later today the C++ committee is likely to approve
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2465r3.pdf
for C++23, and I think implementing that would be a far better use of
our limited resources than providing importable header units.