On Monday, April 8th, 2024 at 11:43 PM, Stephan T. Lavavej
[Matt Borland]
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?
This is a great question. It shouldn't be a problem because we've isolated our use of Boost.Math to our separately compiled sources (a "satellite DLL" or static lib). Classic STL headers and `import std;` just see us calling `extern "C"` functions named `__std_smf_riemann_zeta` and so forth.
(For static linking, where there is no binary isolation, we have a pre-existing problem, unrelated to modules, in that we're dragging in ordinary `boost::` symbols which raises the specter of ODR violations. As for modules, we're including Boost.Math classically, and we expect it to include the Standard Library classically in this mode, so no `import std;` machinery should be sneaking into our static lib, so at least the static lib problem won't get worse.)
Thanks, STL
Thanks for the response. I believe it was Casey (or someone from your team) that asked us about allowing the namespace for those functions to be configured via macro. Let me know if that's something we need to look at again to fix those issues. Matt