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 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.