Experiment with C++20 modules. #783
Conversation
|
@jzmaddock : How do you build it? |
With gcc/msvc the supplied Jamfile will build things, but the special_functions module will fail to build with gcc (core and constants work OK though). Or in msvc IDE you can create a static lib project for the module files and set "build as module interface" under advanced settings. clang, I haven't figured out the command line yet. |
|
Update: I have managed to build the "core" module with clang-14, but not use it, I get: I see other folks around the web see similar errors, but with no solutions thus far :( |
|
@jzmaddock : Has the module situation improved over the past year? I'm wondering if this PR might work now . . |
|
Just tried it with GCC-12 and still see a slew of internal compiler errors. |
[CI SKIP]
|
We'll try again in 2024! |
|
Looks like we might finally be in business: https://www.kitware.com/import-cmake-the-experiment-is-over/ |
|
I pushed a couple of small updates to get this compiling under GCC-13. With C++20 and 23 you can now import std; so that version switch is in as well. I need to try under Clang-18 which came out last week and I think GCC-14 will be out in the next few weeks. |
This now *almost* builds with gcc-13 and clang-18.
|
This almost works with gcc-13 and clang-18. I'm going to try merging develop to this next, as I know that touches some of the problem areas anyway... |
Fixed Conflicts: .gitignore include/boost/math/constants/constants.hpp include/boost/math/policies/error_handling.hpp include/boost/math/policies/policy.hpp include/boost/math/special_functions/detail/bernoulli_details.hpp include/boost/math/special_functions/detail/fp_traits.hpp include/boost/math/special_functions/detail/gamma_inva.hpp include/boost/math/special_functions/detail/igamma_inverse.hpp include/boost/math/special_functions/detail/polygamma.hpp include/boost/math/special_functions/detail/unchecked_factorial.hpp include/boost/math/special_functions/digamma.hpp include/boost/math/special_functions/gamma.hpp include/boost/math/special_functions/log1p.hpp include/boost/math/special_functions/pow.hpp include/boost/math/special_functions/powm1.hpp include/boost/math/special_functions/trigamma.hpp include/boost/math/special_functions/trunc.hpp include/boost/math/tools/config.hpp include/boost/math/tools/convert_from_string.hpp include/boost/math/tools/roots.hpp
|
This now works (such as it is) with MSVC-17.9.5 and clang-18. GCC-13 still ICE's. |
Should we change the file extension of the module to |
|
This sucks, as different compilers require different naming conventions :( I'm easy either way though. |
|
It looks like Dani went with |
|
Cmake 3.30 will give us experimental |
OK folks, here's a bit of an experiment with C++ modules, it works with msvc but gcc leads to a fairly hopeless spiral of internal compiler errors :(
There are 4 modules:
core.
constants
special_functions
and then an overarching "everything" module which just import/export's the others.
I haven't tried with clang - mostly because it's command line use is problematic for modules and doesn't integrate with the build system well.
msvc/gcc needed no modification to the build system to "just work", except that, module dependencies need to be explicitly specified to ensure there is a "builds before" relationship between module definition and user. There's some considerable hot air expended on this subject on the web as it breaks parallel builds, and so may actually make the build time longer if you're not careful.
Anyhow, even though this is a somewhat "failed experiment" at present, I'm submitting as a draft PR for discussion, and we'll see what happens with the next gcc release.