From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-04-08 19:52:13
> > I have questions regarding this - maybe you can help me here:
> > * Let's say I build a Boost module. This #include's std headers in its
> global module fragment.
> > * Now the user compiles their main.cpp, and they import boost and the
> std modules. No includes here.
> > Is this scenario supposed to work? If it is, is it supposed to be
> portable (i.e. defined by the standard)?
>
> It's *supposed* to work portably according to the Standard (N4971
> [std.modules]).
>
> With our current implementation, this is effectively the include/import
> mixing that's challenging for MSVC to handle. (May or may not work in VS
> 2022 17.10. I have a test that ensures that *plain* #include <meow>​ before
> import std;​ works, but not more exotic scenarios. Basically anything
> that leads to the std​ module being dragged in, and *then* the compiler
> seeing an #include <meow>​, will result in the compiler seeing duplicate
> machinery that with the current implementation it cannot reconcile. Having #include
> <meow>​ be within another module's GMF counts AFAIK.) It would be better
> for the Boost module to be built on top of the Standard Library Module
> (both in terms of avoiding current compiler limitations, and for long-term
> cleanliness and build throughput).
>
> STL
>
I see. Is it expected to be fixed in the near future? AFAIK libc++ makes it
work by making the std modules a proxy to the standard headers, with the
"export using" idiom.
I know it'd be better for clean-ness in the long run, but this requires
much more maintenance. I see it difficult right now to get enough buy in
from library authors as to commit to #ifdef-ing out all their standard
includes. If we managed to get a non-intrusive implementation out and this
gained some traction, we could then think to do what you proposed.
Ruben.