Re: On Boost and modules

From: Matt Borland (matt_at_[hidden])
Date: 2024-04-08 19:56:37

> 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

While likely an uncommon issue have you explored cyclic dependencies between modules? For example we are modularizing boost.math now, and would like to import std. In the MSVC case you have boost.math as a submodule for the implementation of C++17 special math. Would this break our ability to import std? If this is uncharted territory I'll experiment with it, and report back.

Matt