[boost] Boost CMake support - Request for Comment

-----Original Message----- From: Boost On Behalf Of Robert Ramey via Boost Sent: Monday, October 1, 2018 7:07 PM

[...]

Scope, Requirements and Features ================================

We presume that submissions will fulfill the applicable requirements of any boost submission. In addition we would like to see the following addressed.

I'll start with the points I can answer (relatively) short and follow up with another email for the rest.

Library Build ------------- “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk Recommends that all libraries - including header only libraries have a CMakeList.txt file. What should this include for Boost Libraries?

[See next email]

Library Test ------------ Should facilities for "testing" be only done by developers? or should users who acquire library packages also be able to test libraries. Should CMake testing results posting be used - CDASH? Should we just skip the issue of Library Testing and continue to depend on Boost Build.

I (a user) would very much like to be able to run boost tests locally, to make sure it works as expected with the specific set of compiler and linker flags chosen for my project. Personally, I don't need to be able to run all boost library unit tests with a single" ctest . " command, but for release management that might be desirable. I guess CDASH would be nice, but that is mainly a question for whoever is in charge of the current testing infrastructure.

Library Packaging ----------------- Is the library packaging facility provide by CMake - CPACK - useful to boost. Should boost libraries be updated to support it?

If I want to use a boost package, I'd use a package manager (vcpkg, conan, apt, brew ...) for that. Unless using CPACK significantly simplifies packaging boost for those package managers, I don't think that would be an advantage

Dependencies ------------ If the above is implemented, can we depend upon CMake to handle library dependencies? Or does some special functionality Do circular dependencies constitute a problem?

CMake can handle circular dependencies. I think the main questions is how a cmake library should find its dependencies. I.e. target_link_libraries(my_lib PUBLIC Boost::other_library1 Boost::other_library2 Boost::other_library2 ) Should be the universal default (of course you can pick another naming convention), but there are different possible ways how those targets could be found if they are not generated by the same (super-) project: - should each project do its own find_package ...? - Should the user do this centrally? - Should boost somehow stick to find_package(BOOST COMPONETS x,y,z) or rather find_package(boost_x), find_package(boost_y) ..? - Should there be a single find_package that pulls in all available header only targets? - Also, should a library first check if a target is already available before calling find_package? Not saying I find all of these choices reasonable. Just that there are different possibilities and if boost absolutely wants or doesn't want to support one of those it should probably be part of the requirements.

Modularity ---------- Currently boost is organized as a tightly integrated group of libraries. This organization manifests itself in a number of ways. We have a Boost "super project" in github. Boost libraries are "sub projects" of this super project. This known structure is exploited by and depended upon by boost tools. Should CMake support continue this policy/design. We distribute boost as "super project". Should we continue to do this or distribute libraries on a library by library basis. Does CMake/CPACK etc. make this "simple"?

For backwards compatibility there should still be a super project (and e.g. the release should probably still provide the headers (or rather a link to them) in one place. However, I'd very much prefer if a common include directory was no longer required by default.

Documentation/testing --------------------- What support should be require for uses of Boost CMake implementation. Documentation, examples, templates for helping library developers. How should the CMake design/implementation be tested?

Other considerations -------------------- add your requirement/features here.

Useful Resources =============== “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 https://github.com/purpleKarrot/Boost.CMake https://www.youtube.com/watch?v=eC9-iRN2b04

Also relevant even if not CMake specific: https://www.youtube.com/watch?v=sBP17HQAQjk Mike