CMake: using boosts own package finding stuff, howto?
in short: CMake does need to change (i'll need to wait for updates) to support newer released boost versions i've heard that Boost supports cmake now directly but i don't get the direct cmake support of boost working with my CMakeLists.txt i know that CMake supports 1.75 in the lastest releases directly but 1.76 and 1.77 are still not on the list and i don't want to wait for CMake release to test new features/betas etc. my system: Ubuntu 21.04/x64, CMake 3.19.4/3.21.0, GCC 10.x Boost 1.75 (want to upgrade to 1.76 soon) my boost build: mkdir ~/dev/3rdparty-liux-gcc cd ~/dev/3rdparty-linux-gcc wget https://dl.bintray.com/boostorg/release/1.75.0/source/boost_1_75_0.tar.bz2 tar -xf boost_1_75_0.tar.bz2 ln -s boost_1_75_0 ./boost cd boost_1_75_0 ./bootstrap.sh ./b2 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 link=static threading=multi --with-graph --with-nowide --with-test --width-config --with-system --with-filesystem --stagedir=./_x64 ln -s _x64/lib lib my simple test hierarchy: boost_using_cmake_tests boost_using_cmake_tests\_build boost_using_cmake_tests\boost_using_cmake boost_using_cmake_tests\boost_using_cmake\CMakeLists.txt cmake_minimum_required (VERSION 3.16) set(Boost_NO_BOOST_CMAKE TRUE) set(Boost_NO_SYSTEM_PATHS TRUE) project (using_boost_with_cmake) set( MY_THIRD_PARTY_LIBS "~/dev/3rdparty-linux-gcc" ) set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost ) set( BOOST_INCLUDEDIR ${BOOST_ROOT}/boost) set( BOOST_LIBRARYDIR ${BOOST_ROOT}/lib) find_package(Boost REQUIRED COMPONENTS unit_test_framework filesystem system) cmake run: using 3.19.4 cmake without 1.75 support ~/dev/boost_using_cmake/_build$ ../../cmake-3.19.4-linux-x86_64/bin/cmake ../boost_using_cmake/ -- The C compiler identification is GNU 10.3.0 -- The CXX compiler identification is GNU 10.3.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Warning at /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204 (message): New Boost version may have incorrect or missing dependencies and imported targets Call Stack (most recent call first): /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326 (_Boost_COMPONENT_DEPENDENCIES) /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:14 (find_package) CMake Warning at /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204 (message): New Boost version may have incorrect or missing dependencies and imported targets Call Stack (most recent call first): /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326 (_Boost_COMPONENT_DEPENDENCIES) /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:14 (find_package) CMake Warning at /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204 (message): New Boost version may have incorrect or missing dependencies and imported targets Call Stack (most recent call first): /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326 (_Boost_COMPONENT_DEPENDENCIES) /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:14 (find_package) -- Found Boost: /home/linux/dev/3rdparty-linux-gcc/boost (found version "1.75.0") found components: unit_test_framework filesystem system -- Configuring done -- Generating done -- Build files have been written to: /home/linux/dev/boost_using_cmake_tests/_build it works but cmake 3.19.4 is missing direct support for 1.75 so its some way "unsupported", cmake does not detect the correct lib names automaticly, only some styles are working etc. i've talked about the problem on the cmake forum and the answer was https://discourse.cmake.org/t/fail-to-use-self-build-boost-1-75-under-ubuntu... Brad King: "...However, Boost upstream now provides a proper CMake package file BoostConfig.cmake which should work for using Boost in any layout..." 1.75 is now directly supported by cmake - but now i want to use 1.76 and the problem re-occures i've tried serveral things to force cmake to use the boost own package findings stuff without any success i hope its possible to use 1.75 and 1.76 in the future without always wait for cmake to support it directly any hints what changes are needed with my CMakeLists.txt to support boost own cmake package finding (and get rid of these problems)?
Am 15.07.21 um 09:17 schrieb Dennis Luehring via Boost:
my boost build: mkdir ~/dev/3rdparty-liux-gcc cd ~/dev/3rdparty-linux-gcc wget https://dl.bintray.com/boostorg/release/1.75.0/source/boost_1_75_0.tar.bz2
tar -xf boost_1_75_0.tar.bz2 ln -s boost_1_75_0 ./boost cd boost_1_75_0 ./bootstrap.sh ./b2 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 link=static threading=multi --with-graph --with-nowide --with-test --width-config --with-system --with-filesystem --stagedir=./_x64 ln -s _x64/lib lib
my simple test hierarchy:
boost_using_cmake_tests boost_using_cmake_tests\_build boost_using_cmake_tests\boost_using_cmake boost_using_cmake_tests\boost_using_cmake\CMakeLists.txt cmake_minimum_required (VERSION 3.16) set(Boost_NO_BOOST_CMAKE TRUE) set(Boost_NO_SYSTEM_PATHS TRUE) project (using_boost_with_cmake) set( MY_THIRD_PARTY_LIBS "~/dev/3rdparty-linux-gcc" ) set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost ) set( BOOST_INCLUDEDIR ${BOOST_ROOT}/boost) set( BOOST_LIBRARYDIR ${BOOST_ROOT}/lib) find_package(Boost REQUIRED COMPONENTS unit_test_framework filesystem system) You explicitely opt-out of Boosts CMake support: set(Boost_NO_BOOST_CMAKE TRUE) You set the wrong folder: set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost )
The INCLUDEDIR/LIBRARYDIR are not required. --> More generic: `export CMAKE_PREFIX_PATH=$HOME/dev/3rdparty-linux-gc/boost_1_75_:$CMAKE_PREFIX_PATH` Then you don't need ANY BOOST_*/Boost_* settings in your CML and can simply call find_package
Am 15.07.2021 um 09:34 schrieb Alexander Grund via Boost:
Am 15.07.21 um 09:17 schrieb Dennis Luehring via Boost:
my boost build: � mkdir ~/dev/3rdparty-liux-gcc � cd ~/dev/3rdparty-linux-gcc � wget https://dl.bintray.com/boostorg/release/1.75.0/source/boost_1_75_0.tar.bz2
� tar -xf boost_1_75_0.tar.bz2 � ln -s boost_1_75_0 ./boost � cd boost_1_75_0 � ./bootstrap.sh � ./b2 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 link=static threading=multi --with-graph --with-nowide --with-test --width-config --with-system --with-filesystem --stagedir=./_x64 � ln -s _x64/lib lib
my simple test hierarchy:
boost_using_cmake_tests boost_using_cmake_tests\_build boost_using_cmake_tests\boost_using_cmake boost_using_cmake_tests\boost_using_cmake\CMakeLists.txt ����� cmake_minimum_required (VERSION 3.16) ����� set(Boost_NO_BOOST_CMAKE TRUE) ����� set(Boost_NO_SYSTEM_PATHS TRUE) ����� project (using_boost_with_cmake) ����� set( MY_THIRD_PARTY_LIBS "~/dev/3rdparty-linux-gcc" ) ����� set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost ) ����� set( BOOST_INCLUDEDIR ${BOOST_ROOT}/boost) ����� set( BOOST_LIBRARYDIR ${BOOST_ROOT}/lib) ����� find_package(Boost REQUIRED COMPONENTS unit_test_framework filesystem system) You explicitely opt-out of Boosts CMake support: set(Boost_NO_BOOST_CMAKE TRUE) You set the wrong folder: set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost )
The INCLUDEDIR/LIBRARYDIR are not required.
--> More generic: `export CMAKE_PREFIX_PATH=$HOME/dev/3rdparty-linux-gc/boost_1_75_:$CMAKE_PREFIX_PATH` Then you don't need ANY BOOST_*/Boost_* settings in your CML and can simply call find_package
thank you - works with cmake 3.19.4+ and boost 1.75/1.76 cmake 3.18.6 (the default under Ubuntu 21.04, and the version i started the jouney with) still does not work and gives the unsupported messages thats why initially setted all the paths that way it seems that the mind version of cmake is 3.19.4 to support finding out of the box - is that correct?
Am 15.07.2021 um 10:38 schrieb Alexander Grund via Boost:
it seems that the mind version of cmake is 3.19.4 to support finding out of the box - is that correct? No, pretty much any CMake version works. Especially with the CMAKE_PREFIX_PATH approach. If it doesn't you misconfigured something
you're right using the CMAKE_PREFIX_PATH approach using environment or directly with list(APPEND CMAKE_PREFIX_PATH ${HAAS_THIRD_PARTY_LIBS}/boost_1_76_0) also works with 3.18.6 - but NOT using set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost_1_76_0 ) - that works only with 3.19.4 the CMake guys forgot(or maybe thought i already tried that) to point me to CMAKE_PREFIX_PATH solution - what would have solved my problem instantly and also said that my problem would be solved with 3.19.4) so i tried to "fix" something unbroken based on a maybe not exact enough issue description - my fault thank you soo much
Am 15.07.21 um 11:08 schrieb Dennis Luehring via Boost:
Am 15.07.2021 um 10:38 schrieb Alexander Grund via Boost:
it seems that the mind version of cmake is 3.19.4 to support finding out of the box - is that correct? No, pretty much any CMake version works. Especially with the CMAKE_PREFIX_PATH approach. If it doesn't you misconfigured something
you're right
using the CMAKE_PREFIX_PATH approach using environment or directly with list(APPEND CMAKE_PREFIX_PATH ${HAAS_THIRD_PARTY_LIBS}/boost_1_76_0)
also works with 3.18.6 - but NOT using set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost_1_76_0 ) - that works only with 3.19.4
I think the correct variable to set here would have been Boost_ROOT or Boost_DIR BOOST_ROOT is compatibility IIRC
also works with 3.18.6 - but NOT using set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost_1_76_0 ) - that works only with 3.19.4
FWIW: BOOST_ROOT is honored since 3.19.0: https://github.com/Kitware/CMake/commit/4b2a61946fdb77ab37b66b1d2b81d2d77453... Anyway I suggest to always use CMAKE_PREFIX_PATH for any dependency
Am 15.07.2021 um 11:25 schrieb Alexander Grund via Boost:
also works with 3.18.6 - but NOT using set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost_1_76_0 ) - that works only with 3.19.4
FWIW: BOOST_ROOT is honored since 3.19.0: https://github.com/Kitware/CMake/commit/4b2a61946fdb77ab37b66b1d2b81d2d77453...
good to know
Anyway I suggest to always use CMAKE_PREFIX_PATH for any dependency
same suggestion comes for the Qt guys when upgrading to Qt6 btw: i've copied the boost integration stuff from the internet and many samples using the Boost_INCLUDE_DIR etc. are complete uppercase - i've copied that two but now i cleaned all my CMakeLists.txt + using CMAKE_PREFIX_PATH and everything works as expected another big thank you!
Am 15.07.21 um 09:17 schrieb Dennis Luehring via Boost:
in short: CMake does need to change (i'll need to wait for updates) to support newer released boost versions
i've heard that Boost supports cmake now directly but i don't get the direct cmake support of boost working with
my CMakeLists.txt
i know that CMake supports 1.75 in the lastest releases directly but 1.76 and 1.77 are still not on the list and i don't want
to wait for CMake release to test new features/betas etc.
my system:
Ubuntu 21.04/x64, CMake 3.19.4/3.21.0, GCC 10.x
Boost 1.75 (want to upgrade to 1.76 soon)
my boost build: mkdir ~/dev/3rdparty-liux-gcc cd ~/dev/3rdparty-linux-gcc wget https://dl.bintray.com/boostorg/release/1.75.0/source/boost_1_75_0.tar.bz2
tar -xf boost_1_75_0.tar.bz2 ln -s boost_1_75_0 ./boost cd boost_1_75_0 ./bootstrap.sh ./b2 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 link=static threading=multi --with-graph --with-nowide --with-test --width-config --with-system --with-filesystem --stagedir=./_x64 ln -s _x64/lib lib
my simple test hierarchy:
boost_using_cmake_tests boost_using_cmake_tests\_build boost_using_cmake_tests\boost_using_cmake boost_using_cmake_tests\boost_using_cmake\CMakeLists.txt cmake_minimum_required (VERSION 3.16) set(Boost_NO_BOOST_CMAKE TRUE) set(Boost_NO_SYSTEM_PATHS TRUE) project (using_boost_with_cmake) set( MY_THIRD_PARTY_LIBS "~/dev/3rdparty-linux-gcc" ) set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost ) set( BOOST_INCLUDEDIR ${BOOST_ROOT}/boost) set( BOOST_LIBRARYDIR ${BOOST_ROOT}/lib) find_package(Boost REQUIRED COMPONENTS unit_test_framework filesystem system)
One remark: Here you are explicitly depending on CMake's `FindBoost` script, because you neither use the `CONFIG` nor `NO_MODULE` argument (or any other argument not specified in the basic signature) for `find_package`. [1] Unless you explicitly set the `CMAKE_FIND_PACKAGE_PREFER_CONFIG` variable `find_package` always tries the "Module" mode first. And if it finds a suitable `Find*` script it will not try the "Config" mode (even if the `Find*` script is unable to find the package). That your `find_package(Boost ...)` call still tries the "Config" mode (if you again remove the `Boost_NO_BOOST_CMAKE` variable or set it to `FALSE`)is only due to the fact that the `FindBoost` script explicitly tries the `Config` mode first (unless you set the `Boost_NO_BOOST_CMAKE` variable to `TRUE`). So, in general I always recommend to explicitly use `find_package` in "Config" mode if one knows that the searched package was installed with a config-file for importing. For Boost this should be true since Boost 1.70.0. (Installing it without the config-file is not very sensible.) Happy cmaking, Deniz [1] https://cmake.org/cmake/help/latest/command/find_package.html#full-signature...
cmake run:
using 3.19.4 cmake without 1.75 support
~/dev/boost_using_cmake/_build$ ../../cmake-3.19.4-linux-x86_64/bin/cmake ../boost_using_cmake/ -- The C compiler identification is GNU 10.3.0 -- The CXX compiler identification is GNU 10.3.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Warning at /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204
(message): New Boost version may have incorrect or missing dependencies and imported targets Call Stack (most recent call first): /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326
(_Boost_COMPONENT_DEPENDENCIES) /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935
(_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:14 (find_package)
CMake Warning at /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204
(message): New Boost version may have incorrect or missing dependencies and imported targets Call Stack (most recent call first): /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326
(_Boost_COMPONENT_DEPENDENCIES) /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935
(_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:14 (find_package)
CMake Warning at /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204
(message): New Boost version may have incorrect or missing dependencies and imported targets Call Stack (most recent call first): /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326
(_Boost_COMPONENT_DEPENDENCIES) /home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935
(_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:14 (find_package)
-- Found Boost: /home/linux/dev/3rdparty-linux-gcc/boost (found version "1.75.0") found components: unit_test_framework filesystem system -- Configuring done -- Generating done -- Build files have been written to: /home/linux/dev/boost_using_cmake_tests/_build
it works but cmake 3.19.4 is missing direct support for 1.75 so its some way "unsupported", cmake does not detect the correct lib names automaticly, only some styles are working etc.
i've talked about the problem on the cmake forum and the answer was
https://discourse.cmake.org/t/fail-to-use-self-build-boost-1-75-under-ubuntu...
Brad King: "...However, Boost upstream now provides a proper CMake package file BoostConfig.cmake which should work for using Boost in any layout..."
1.75 is now directly supported by cmake - but now i want to use 1.76 and the problem re-occures
i've tried serveral things to force cmake to use the boost own package findings stuff without any success i hope its possible to use 1.75 and 1.76 in the future without always wait for cmake to support it directly
any hints what changes are needed with my CMakeLists.txt to support boost own cmake package finding (and get rid of these problems)?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir@benocs.com www.benocs.com Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378
Am 15.07.2021 um 13:52 schrieb Deniz Bahadir via Boost:
One remark:
Here you are explicitly depending on CMake's `FindBoost` script, because you neither use the `CONFIG` nor `NO_MODULE` argument (or any other argument not specified in the basic signature) for `find_package`. [1] Unless you explicitly set the `CMAKE_FIND_PACKAGE_PREFER_CONFIG` variable `find_package` always tries the "Module" mode first. And if it finds a suitable `Find*` script it will not try the "Config" mode (even if the `Find*` script is unable to find the package). That your `find_package(Boost ...)` call still tries the "Config" mode (if you again remove the `Boost_NO_BOOST_CMAKE` variable or set it to `FALSE`)is only due to the fact that the `FindBoost` script explicitly tries the `Config` mode first (unless you set the `Boost_NO_BOOST_CMAKE` variable to `TRUE`).
So, in general I always recommend to explicitly use `find_package` in "Config" mode if one knows that the searched package was installed with a config-file for importing. For Boost this should be true since Boost 1.70.0. (Installing it without the config-file is not very sensible.)
Happy cmaking, Deniz
i've reworked my CMakeLists.txt using that schema, using CMAKE_PREFIX_PATH and CONFIG works for linux, windows - includes and libraries correctly set to make/VStudio project ------------------- cmake_minimum_required(VERSION 3.14) project (my_test) if(UNIX AND NOT APPLE) set( MY_BOOST_DIR "/home/linux/temp/boost_1_75_0/_x64/lib/cmake" ) else() set( MY_BOOST_DIR "D:/temp/boost_1_75_0/_x64/lib/cmake" ) endif() list(APPEND CMAKE_PREFIX_PATH ${MY_BOOST_DIR}) add_executable(test test.cpp) find_package(Boost CONFIG REQUIRED COMPONENTS unit_test_framework) message(STATUS "!! Boost_FOUND => ${Boost_FOUND}") IF (Boost_FOUND) message(STATUS "!! Boost_INCLUDE_DIRS => ${Boost_INCLUDE_DIRS}") message(STATUS "!! BOOST_INCLUDE_DIR => ${BOOST_INCLUDE_DIR}") message(STATUS "!! BOOST_INCLUDEDIR => ${BOOST_INCLUDEDIR}") message(STATUS "!! Boost_LIBRARY_DIRS => ${Boost_LIBRARY_DIRS}") message(STATUS "!! BOOST_LIBRARYDIR => ${BOOST_LIBRARYDIR}") message(STATUS "!! Boost_LIBRARY_DIR => ${Boost_LIBRARY_DIR}") message(STATUS "!! Boost_LIBRARY_DIR_RELEASE => ${Boost_LIBRARY_DIR_RELEASE}") message(STATUS "!! Boost_LIBRARY_DIR_DEBUG => ${Boost_LIBRARY_DIR_DEBUG}") target_link_libraries(test ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}) ENDIF() ------------------ the only thing i don't understand (after testing/working with serveral "variants" of boost cmake integration) is that not all of the find_package result-Vars are set - but this is the first time that every CMake version or Platform returns absolute the same results but Boost_LIBRARY_DIRS is not set anymore - but maybe its just not needed output: CMake 3.14,3.18,3.21 giving this output on windows and linux (with a different path) -- !! Boost_FOUND => 1 -- !! Boost_INCLUDE_DIRS => D:/temp/boost_1_75_0 -- !! BOOST_INCLUDE_DIR => -- !! BOOST_INCLUDEDIR => -- !! Boost_LIBRARY_DIRS => -- !! BOOST_LIBRARYDIR => -- !! Boost_LIBRARY_DIR => -- !! Boost_LIBRARY_DIR_RELEASE => -- !! Boost_LIBRARY_DIR_DEBUG => i know that some of these (nearly identical!!!) vars are find_package-returns, cache-var or hints for finding the package - i just print them all to understand whats happening does that mean i've found the holy grail of clean boost cmake integration? are the result correct that way (my co-worker said this "/lib/cmake" at the end of CMAKE_PREFIX_PATH seems wrong - but Qt6 is it doing the same way - so i think he is wrong) thank for your help
the only thing i don't understand (after testing/working with serveral "variants" of boost cmake integration) is
that not all of the find_package result-Vars are set - but this is the first time that every CMake version or Platform returns absolute the same results
but Boost_LIBRARY_DIRS is not set anymore - but maybe its just not needed All of them are not needed at all and not set by the CONFIG files. The FindBoost module has explicit code to add those for legacy reasons. In "good" CMake you are supposed to use the targets so all those variables don't matter for ages now. does that mean i've found the holy grail of clean boost cmake integration? Not sure what you mean here. are the result correct that way (my co-worker said this "/lib/cmake" at the end of CMAKE_PREFIX_PATH seems wrong - but Qt6 is it doing the same way - so i think he is wrong)
It is a PREFIX path, so yes, the lib/cmake is wrong. Besides that: CMakeLists should be independent of your environment. So setting CMAKE_PREFIX_PATH with hard-coded paths to your local system is wrong. You are supposed to set the CMAKE_PREFIX_PATH env variable, e.g. in your bashrc, profile file or manually in the shell or install boost to a standard path like /usr
Am 16.07.2021 um 09:53 schrieb Alexander Grund via Boost:
the only thing i don't understand (after testing/working with serveral "variants" of boost cmake integration) is
that not all of the find_package result-Vars are set - but this is the first time that every CMake version or Platform returns absolute the same results
but Boost_LIBRARY_DIRS is not set anymore - but maybe its just not needed All of them are not needed at all and not set by the CONFIG files. The FindBoost module has explicit code to add those for legacy reasons. In "good" CMake you are supposed to use the targets so all those variables don't matter for ages now.
im working in serveral different customer projects that use this legacy style which gets copied over and over - so everyone thinks that legacy stuff is the "official" way also many/most of the "examples" on the internet are using the legcy style - more or less in complete wrong way - that is the base i've started with also the discussion on the cmake forum often contain tips that are very legacy or even wrong when it comes to boost integration - would be great to have some HOW-to-do-it correct tutorial on the boost web page (i did't found any good information on boost.org) thank for clearing that all up, also thanks @Deniz
does that mean i've found the holy grail of clean boost cmake integration? Not sure what you mean here.
as stated above - i saw every old dirty trick to use boost with cmake - and now i think most of them just completely wrong - that cost some days to figure it out and the current solution is how i though it should be done (while fighting with my co-workers) now i need to make my other co-workers understand that
are the result correct that way (my co-worker said this "/lib/cmake" at the end of CMAKE_PREFIX_PATH seems wrong - but Qt6 is it doing the same way - so i think he is wrong)
It is a PREFIX path, so yes, the lib/cmake is wrong.
it works with and without lib/cmake but i also got the feeling that its not correct - thanks so its just the path i used with --stagedir= while building boost
Besides that: CMakeLists should be independent of your environment. So setting CMAKE_PREFIX_PATH with hard-coded paths to your local system is wrong. You are supposed to set the CMAKE_PREFIX_PATH env variable, e.g. in your bashrc, profile file or manually in the shell or install boost to a standard path like /usr
the hardcoded path are only in this example - normaly these are based on cmake command line parameters or environment variables
when it comes to boost integration - would be great to have some HOW-to-do-it correct tutorial Sure: find_package(Boost 1.71.0 REQUIRED COMPONENTS unit_test_framework) # Optionally with CONFIG if you require a recent enough Boost target_link_libraries(foo PUBLIC Boost::unit_test_framework)
Done. Nothing more than that. Plus it pretty much works for EVERY dependency
and the current solution is how i though it should be done (while fighting with my co-workers) Your current solution uses variables: target_link_libraries(test ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}) Replace that by the target, then you are fine now i need to make my other co-workers understand that Tell them this: OOP is key. OOP in CMake means targets. Work with targets and target_* functions, not e.g. `include_directories` it works with and without lib/cmake but i also got the feeling that its not correct - thanks so its just the path i used with --stagedir= while building boost This is documented in the CMake docs, that CMake searchs the <PREFIX>/lib/cmake folder: https://cmake.org/cmake/help/v3.9/command/find_package.html#command:find_pac... the hardcoded path are only in this example - normaly these are based on cmake command line parameters or environment variables Try to avoid touching CMAKE_PREFIX_PATH in a CML unless you install stuff in the same CMake to that path. Require users to export that env variable instead. This makes your files more portable. Having to set different env vars for every software you install makes a mess.
Am 16.07.21 um 10:17 schrieb Dennis Luehring via Boost:
when it comes to boost integration - would be great to have some HOW-to-do-it correct tutorial
on the boost web page (i did't found any good information on boost.org)
thank for clearing that all up, also thanks @Deniz
does that mean i've found the holy grail of clean boost cmake integration? Not sure what you mean here.
as stated above - i saw every old dirty trick to use boost with cmake - and now i think
most of them just completely wrong - that cost some days to figure it out
and the current solution is how i though it should be done (while fighting with my co-workers)
now i need to make my other co-workers understand that
Am 17.07.2021 um 19:59 schrieb Deniz Bahadir via Boost:
as stated above - i saw every old dirty trick to use boost with cmake - and now i think
most of them just completely wrong - that cost some days to figure it out
and the current solution is how i though it should be done (while fighting with my co-workers)
now i need to make my other co-workers understand that
I always like to point interested people to my two CMake talks, where I explain the difference between traditional and modern CMake and where I also have some examples for how to use Boost with CMake: * ["More Modern CMake"](https://youtu.be/y7ndUhdQuU8) * ["Oh No! More Modern CMake"](https://youtu.be/y9kSr5enrSk)
thank you for these 2 hours visual freshup of my cmake knowledge :)
Am 19.07.21 um 14:14 schrieb Dennis Luehring via Boost:
Am 17.07.2021 um 19:59 schrieb Deniz Bahadir via Boost:
as stated above - i saw every old dirty trick to use boost with cmake - and now i think
most of them just completely wrong - that cost some days to figure it out
and the current solution is how i though it should be done (while fighting with my co-workers)
now i need to make my other co-workers understand that
I always like to point interested people to my two CMake talks, where I explain the difference between traditional and modern CMake and where I also have some examples for how to use Boost with CMake: * ["More Modern CMake"](https://youtu.be/y7ndUhdQuU8) * ["Oh No! More Modern CMake"](https://youtu.be/y9kSr5enrSk)
thank you for these 2 hours visual freshup of my cmake knowledge :) You are welcome. And thank you for watching. :-)
-- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir@benocs.com www.benocs.com Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378
Dennis Luehring wrote:
if(UNIX AND NOT APPLE) set( MY_BOOST_DIR "/home/linux/temp/boost_1_75_0/_x64/lib/cmake" ) else() set( MY_BOOST_DIR "D:/temp/boost_1_75_0/_x64/lib/cmake" ) endif()
list(APPEND CMAKE_PREFIX_PATH ${MY_BOOST_DIR})
add_executable(test test.cpp)
find_package(Boost CONFIG REQUIRED COMPONENTS unit_test_framework)
In principle this can equivalently be find_package(Boost CONFIG REQUIRED COMPONENTS unit_test_framework PATHS "/home/linux/temp/boost_1_75_0/_x64" "D:/temp/boost_1_75_0/_x64") although in the real project the paths probably shouldn't be hardcoded in the CMakeLists.txt file.
target_link_libraries(test ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
This should be target_link_libraries(test Boost::unit_test_framework) The variables are old style CMake and shouldn't be used nowadays.
Am 16.07.2021 um 10:30 schrieb Peter Dimov via Boost:
� target_link_libraries(test ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}) This should be
target_link_libraries(test Boost::unit_test_framework)
The variables are old style CMake and shouldn't be used nowadays.
is there some setting to get such usage as warning - or do i need to follow the cmake documentation to understand what nowdays prefered? set(CMAKE_WARN_DEPRECATED TRUE) does not really help i think im surrounded by many lines of legacy cmake code
participants (4)
-
Alexander Grund -
Deniz Bahadir -
Dennis Luehring -
pdimov＠gmail.com