Boost_VERSION widely different between old CMake and new CMake find_package
I have the following CMakeLists.txt: project(Boost CXX) cmake_minimum_required(VERSION 3.0) FIND_PACKAGE(Boost COMPONENTS filesystem REQUIRED) message( ${Boost_VERSION} ) In Ubuntu 18.04 LTS (Bionic) this produces: cmake ../ -- The CXX compiler identification is GNU 7.4.0 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Boost version: 1.65.1 -- Found the following Boost libraries: -- filesystem -- system 106501 -- Configuring done -- Generating done -- Build files have been written to: /root/foo/build As in Boost_VERSION is set to 106501 In Ubuntu 20.04 LTS (Focal, devel release) which uses boost 1.71 with boost cmake files: -- The CXX compiler identification is GNU 9.2.1 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found version "1.71.0") found components: filesystem 1.71.0 -- Configuring done -- Generating done -- Build files have been written to: /home/xnox/canonical/boost/debian/tests/srcs/filesystem/foo As in Boost_VERSION is set to 1.71.0 Now, lot of projects have Boost version comparison already and 1.71.0 is less than 106501. This creates problems for example when trying to detect and use new-style pythonXY components, filesystem v3 api, etc. For example I found in Ubuntu packages stanzas like: if (${Boost_VERSION} LESS 104400) Can we please fix Boost_VERSION in the new-style cmake to be compatible / same / similar / higher than the old Boost_VERSION string? -- Regards, Dimitri.
Am 05.02.20 um 13:47 schrieb Dimitri John Ledkov via Boost:
As in Boost_VERSION is set to 1.71.0
Now, lot of projects have Boost version comparison already and 1.71.0 is less than 106501. This creates problems for example when trying to detect and use new-style pythonXY components, filesystem v3 api, etc.
For example I found in Ubuntu packages stanzas like: if (${Boost_VERSION} LESS 104400)
Can we please fix Boost_VERSION in the new-style cmake to be compatible / same / similar / higher than the old Boost_VERSION string? I'd say: No.
Even CMake is now reporting the version in the "correct" x.y.z format starting from CMake 3.15: https://cmake.org/cmake/help/v3.15/policy/CMP0093.html It was a mistake on their side to ever report it otherwise. There are already 3 Boost releases with BoostConfigs out there that report the version "correctly" so changing this now will lead to failures in other peoples projects. So I'd rather have people fix their CMLs instead. They can also check for and use Boost_VERSION_MACRO if they want.| |
On Wed, 5 Feb 2020 at 13:07, Alexander Grund via Boost
Am 05.02.20 um 13:47 schrieb Dimitri John Ledkov via Boost:
As in Boost_VERSION is set to 1.71.0
Now, lot of projects have Boost version comparison already and 1.71.0 is less than 106501. This creates problems for example when trying to detect and use new-style pythonXY components, filesystem v3 api, etc.
For example I found in Ubuntu packages stanzas like: if (${Boost_VERSION} LESS 104400)
Can we please fix Boost_VERSION in the new-style cmake to be compatible / same / similar / higher than the old Boost_VERSION string? I'd say: No.
Even CMake is now reporting the version in the "correct" x.y.z format starting from CMake 3.15: https://cmake.org/cmake/help/v3.15/policy/CMP0093.html It was a mistake on their side to ever report it otherwise.
There are already 3 Boost releases with BoostConfigs out there that report the version "correctly" so changing this now will lead to failures in other peoples projects. So I'd rather have people fix their CMLs instead. They can also check for and use Boost_VERSION_MACRO if they want.|
Ok that's cool. I'll contribute patches to the affected projects to adjust for the correct world order. -- Regards, Dimitri.
participants (2)
-
Alexander Grund -
Dimitri John Ledkov