[boost] Boost CMake support - Request for Comment

Subject: [boost] Boost CMake support - Request for Comment
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-10-15 09:15:44

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> 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 . <some_parameter>" 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