Follow-up to the follow-up of the CMake follow-up
In branch feature/install-cmake-config-2 of the superproject, you can find an improved version of the award-winning work presented in my previous follow-up. This one integrates into the top-level "b2 install" and "b2 stage" and installs (or, respectively, stages) the CMake configuration files necessary for find_package to work. The instructions for trying it out are the same as last time: git clone --recursive --depth 64 -b feature/install-cmake-config-2 https://githib.com/boostorg/boost bootstrap b2 headers b2 install then add the installation prefix to CMAKE_PREFIX_PATH. An example CMakeLists.txt could look like this: cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) list(APPEND CMAKE_PREFIX_PATH C:/Boost) find_package(boost_filesystem 1.63.0 REQUIRED) find_package(boost_program_options 1.63.0 REQUIRED) # disable autolink add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::filesystem boost::program_options)
In branch feature/install-cmake-config-2 of the superproject, you can find an improved version of the award-winning work presented in my previous follow-up. This one integrates into the top-level "b2 install" and "b2 stage" and installs (or, respectively, stages) the CMake configuration files necessary for find_package to work.
... and I'm grateful to Rene Rivera and Vladimir Prus for their patient help with Boost.Build.
Olaf van der Spek wrote:
On Wed, Jul 5, 2017 at 8:39 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
list(APPEND CMAKE_PREFIX_PATH C:/Boost)
Is this right? Hard-coding the path of a dependency doesn't look right.
That's just my test CMakeLists.txt. You don't have to copy it. I grew tired of specifying -DCMAKE_PREFIX_PATH on each configure.
In branch feature/install-cmake-config-2 of the superproject, you can find an improved version of the award-winning work presented in my previous follow-up. This one integrates into the top-level "b2 install" and "b2 stage" and installs (or, respectively, stages) the CMake configuration files necessary for find_package to work.
[...]
I think this is a very good start! It shows that we can automate part of the process of creating the CMake XYZConfig.cmake files for existing libraries, which is nice. However, the resulting XYZConfig files are not always sufficient, for example Boost.Interprocess, which requires additional libraries to link. Specifically, the config file for Boost.Interprocess would need to specify something along the lines of: if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux") target_link_libraries(boost_interprocess INTERFACE -lrt) endif() I don't think these things can be generated automatically, and I expect that a number of libraries will require manual attention to provide proper integration. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Follow-up-to-the-follow-up-of-the-CMake-f... Sent from the Boost - Dev mailing list archive at Nabble.com.
Louis Dionne wrote:
Specifically, the config file for Boost.Interprocess would need to specify something along the lines of:
if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux") target_link_libraries(boost_interprocess INTERFACE -lrt) endif()
Yes, and there's also the problem that some libraries don't have the same name as their directory. Specifically, Test and Stacktrace, but there may be others. There was also Math, but I made it header-only.
On Thu, 2017-07-13 at 10:55 -0700, Louis Dionne via Boost wrote:
In branch feature/install-cmake-config-2 of the superproject, you can find an improved version of the award-winning work presented in my previous follow-up. This one integrates into the top-level "b2 install" and "b2 stage" and installs (or, respectively, stages) the CMake configuration files necessary for find_package to work.
[...]
I think this is a very good start! It shows that we can automate part of the process of creating the CMake XYZConfig.cmake files for existing libraries, which is nice. However, the resulting XYZConfig files are not always sufficient, for example Boost.Interprocess, which requires additional libraries to link. Specifically, the config file for Boost.Interprocess would need to specify something along the lines of:
if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux") target_link_libraries(boost_interprocess INTERFACE -lrt) endif()
Actually, using the scripts I have here: https://github.com/pfultz2/boost-cmake This will let you inject extra cmake code for projects. That's how I generate code for Boost.Context, which needs a lot of custom work. The same could be done for Boost.Interprocess. Its fairly simple to add if you would like to add your patches. It currently can build all of boost, but there is some more work that needs to be done, including adding more tests, and disabling libraries such as MPI or Python that need external dependencies.
On Thu, 2017-07-13 at 10:55 -0700, Louis Dionne via Boost wrote:
In branch feature/install-cmake-config-2 of the superproject, you can find an improved version of the award-winning work presented in my previous follow-up. This one integrates into the top-level "b2 install" and "b2 stage" and installs (or, respectively, stages) the CMake configuration files necessary for find_package to work.
[...]
I think this is a very good start! It shows that we can automate part of the process of creating the CMake XYZConfig.cmake files for existing libraries, which is nice. However, the resulting XYZConfig files are not always sufficient, for example Boost.Interprocess, which requires additional libraries to link. Specifically, the config file for Boost.Interprocess would need to specify something along the lines of:
if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux") target_link_libraries(boost_interprocess INTERFACE -lrt) endif()
Actually, using the scripts I have here:
https://github.com/pfultz2/boost-cmake
This will let you inject extra cmake code for projects. That's how I generate code for Boost.Context, which needs a lot of custom work. The same could be done for Boost.Interprocess. Its fairly simple to add if you would like to add your patches.
It currently can build all of boost, but there is some more work that needs to be done, including adding more tests, and disabling libraries such as MPI or Python that need external dependencies.
I looked quickly at your solution, and it appears that you're writing quite a bit of custom CMake code (and I don't see how things could be any different). This also appears to be missing some things like the fact that Hana has a requirement on C++14: target_compile_features(hana INTERFACE cxx_std_14) Or are you reusing Hana's CMakeLists.txt? I'm not sure that's going to work out of the box, since I have not written Hana's CMakeLists.txt with the idea that one would use it through add_subdirectory. I think your (and Peter's) tools are really cool and they show us how we can use tooling to help us migrate if/when we decide to do so. In the end, I do believe we'd have some manual work to do, but that's fine IMO. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Follow-up-to-the-follow-up-of-the-CMake-f... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Thu, 2017-07-13 at 12:58 -0700, Louis Dionne via Boost wrote:
On Thu, 2017-07-13 at 10:55 -0700, Louis Dionne via Boost wrote:
In branch feature/install-cmake-config-2 of the superproject, you can find an improved version of the award-winning work presented in my previous follow-up. This one integrates into the top-level "b2 install" and "b2 stage" and installs (or, respectively, stages) the CMake configuration files necessary for find_package to work.
[...]
I think this is a very good start! It shows that we can automate part of the process of creating the CMake XYZConfig.cmake files for existing libraries, which is nice. However, the resulting XYZConfig files are not always sufficient, for example Boost.Interprocess, which requires additional libraries to link. Specifically, the config file for Boost.Interprocess would need to specify something along the lines of:
if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux") target_link_libraries(boost_interprocess INTERFACE -lrt) endif()
Actually, using the scripts I have here:
https://github.com/pfultz2/boost-cmake
This will let you inject extra cmake code for projects. That's how I generate code for Boost.Context, which needs a lot of custom work. The same could be done for Boost.Interprocess. Its fairly simple to add if you would like to add your patches.
It currently can build all of boost, but there is some more work that needs to be done, including adding more tests, and disabling libraries such as MPI or Python that need external dependencies.
I looked quickly at your solution, and it appears that you're writing quite a bit of custom CMake code (and I don't see how things could be any different).
Not really writing any custom cmake code. It essientially follows Daniel's effective cmake. Where are you seeing custom cmake code? The only part is that I check the dependencies are available before I link them, so I write: if(boost_core_FOUND) target_link_libraries(boost_hana INTERFACE boost::core) endif() I would like to change that. This was kind of hack to make some libraries optional. I need to think about better supporting optional boost libraries from the `add_subdirectory` level. That is the user may not want to build python or mpi, so there should be a way to disable them, however, some libraries will still look for those dependencies. I think this is more of a problem of the mess of dependencies we have now. Hopefully, I can find a cleaner solution.
This also appears to be missing some things like the fact that Hana has a requirement on C++14:
target_compile_features(hana INTERFACE cxx_std_14)
I dont do that because: * It doesnt work with cmake 3.5, which is what I am targeting * It can break ABI compatibilty adding in a C++14 flag. * It also doesnt work with C++ versions it doesnt know about, such as C++AMP or C++20. If users want to use C++14 it should be added to the toolchain, that way all libraries compile with it, which makes all ABIs consistent. For now, Hana can just check if the features necessary are avaiable during configure, and stop if the toolchain does not have a C++14 capable compiler. Once this features matures more with cmake, we should definitely start using it, but its just not there yet.
Or are you reusing Hana's CMakeLists.txt?
No, because Hana's cmake uses `find_package(Boost)`, which will not find its dependencies correctly nor does Hana makes its dependencies transitive in its config cmake file. Instead, I generated cmake to use and generate the proper cmake config files.
I'm not sure that's going to work out of the box, since I have not written Hana's CMakeLists.txt with the idea that one would use it through add_subdirectory.
True, but the generated one will work both standalone and through `add_subdirectory`. Of course, it doesn't run the tests, and there maybe more changes we want to make.
I think your (and Peter's) tools are really cool and they show us how we can use tooling to help us migrate if/when we decide to do so. In the end, I do believe we'd have some manual work to do, but that's fine IMO.
When we want to support cmake running the tests, there will be a lot of manual work with that. I don't see an easy way to automate it. The nice thing about the automated scripts is we could use them to provide "experimental" versions of boost cmake now, so we can guage user demand for cmake. We just need some testing infrastructure to ensure that the plumbing is correct.
participants (4)
-
Louis Dionne -
Olaf van der Spek -
paul -
Peter Dimov