Lucas Colley wrote:
Dear boost developers,
Subprojects like `math` define CMAKE_PROJECT_VERSION in terms of BOOST_SUPERPROJECT_VERSION via:
``` project(boost_math VERSION "${BOOST_SUPERPROJECT_VERSION}" LANGUAGES CXX) ```
This is clearly handy to save a few seconds in the release process, but it means that if one wants to use the subproject standalone (where BOOST_SUPERPROJECT_VERSION is undefined), CMAKE_PROJECT_VERSION is also undefined.
This is a problem for me as I am trying to make boost_math a Meson-CMake subproject of SciPy. This would enable us to un-vendor boost_math from SciPy, such that a distro can instead use SciPy with boost_math as a system library. We would only fall back to embedding the boost_math source when it is not installed as a system library.
When the boost_math source is embedded, CMAKE_PROJECT_VERSION is parsed to check that we have the correct version to work with SciPy, but we get an error that the version is undefined. This could be solved by defining the version directly in the math subproject instead of in terms of BOOST_SUPERPROJECT_VERSION. The alternative solution of embedding the entire boost source is not suitable for us, since all we need is math.
Would it be possible to switch to defining CMAKE_PROJECT_VERSION directly in subprojects?
This means that after each Boost release, all these CMakeLists.txt files would need to be updated by their maintainers so that the version remains correct. I do this in Mp11 https://github.com/boostorg/mp11/blob/03a2d3ae5f0b42bb7e6c3d1af19dd9c978b848... but it's a lot of churn and these versions will very likely go out of sync for at least half of the libraries if we rely on the maintainers to keep them up to date. If the Boost.Math team wants to maintain the version separately, that's fine and up to them, but I would advise adding a test that the version is correct, like I have in Mp11. https://github.com/boostorg/mp11/blob/03a2d3ae5f0b42bb7e6c3d1af19dd9c978b848... https://github.com/boostorg/mp11/blob/develop/test/check_cmake_version.cpp