Re: [cmake] Define CMAKE_PROJECT_VERSION for standalone subprojects

From: Lucas Colley (lucas.colley8_at_[hidden])
Date: 2024-09-15 19:27:25

Thanks Peter. I would be happy with just Boost.Math adopting what you do in Mp11. I asked the more general question as it is possible that others may run into a similar situation with other subprojects.

> On 15 Sep 2024, at 19:52, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> 
> 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/03a2d3ae5f0b42bb7e6c3d1af19dd9c978b84896/CMakeLists.txt#L7
> 
> 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/03a2d3ae5f0b42bb7e6c3d1af19dd9c978b84896/test/CMakeLists.txt#L10
> https://github.com/boostorg/mp11/blob/develop/test/check_cmake_version.cpp
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost