Re: [boost] Boost CMake support - Request for Comment

Subject: Re: [boost] Boost CMake support - Request for Comment
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-10-01 18:00:11

On 10/1/2018 1:07 PM, Robert Ramey via Boost wrote:
> Background
> ==========
> 
> My personal knowledge of build systems is somewhat limited.
> 
> a) I don't really understand CMake all that well.  I have made 
> CMakeLists.txt files for both the serialization library and the safe 
> numerics libraries as an aid to build and maintain IDE and make files 
> used in running tests and posting results to CDash.
> 
> b) I don't really understand our current system, Boost Build, very well 
> either.  I've made jam files for building and running tests for the 
> serialization and safe numerics libraries.
> 
> c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video 
> from C++Now 2017  “Effective CMake" - 
> https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly.
> 
> Despite my lack of knowledge in this area, or perhaps because of it, 
> I've volunteered to direct the effort to evolve Boost so that users of 
> Boost can avail themselves of the benefits of CMake.  This effort will 
> be organized as follows:
> 
> a) A discussion on the boost developers mailing list with the goal of 
> reaching a consensus as to what benefits CMake can and should provide to 
> users and developers of Boost.  This effort will commence with the 
> posting of this notice.  I hope that this discussion can be more or less 
> resolved within 30 days.
> 
> b) I will then synthesize from the above discussion a call for proposals 
> which lists the requirements and requirements.
> 
> c) Those proposing CMake for boost will have approximately 90 days to 
> prepare their proposals.  Their proposal are expected to look similar to 
> a boost library proposal.  That is they are expected to have some 
> (CMake) code, along with tests, documentation including tutorials and 
> reference.  This is only an expectation.  It's conceivable that such a 
> proposal might only contain conventions and and samples of what boost 
> library should contain to fulfill the requirements. As with boost 
> libraries, submissions are not required to totally complete.  But they 
> have to be sufficiently complete to convince reviewers the the 
> submission fulfills the stated requirements and can be finished in good 
> time.
> 
> d) After the 90 day period, submissions will be reviewed simultaneously. 
>  Â Note that this is at a variance from normal boost procedure of 
> reviewing submissions one at a time.  Since we expect to receive a 
> number of submissions and only one can be accepted, the normal boost 
> protocol can't really function.  Target date for this review is 1 
> February 2019.
> 
> e) After the review period the review manager will prepare a report 
> which includes the decision of which submission will be accepted into 
> the official boost distribution.  Currently, I, Robert Ramey, expect to 
> be review manager.  However, it's possible that this by the time the 
> review is undertaken, this coveted position could be assigned to some 
> more worthy candidate.
> 
> 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.
> 
> 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?
> 
> 
> 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.
> 
> Library Packaging
> -----------------
>  Â Â Â Â Is the library packaging facility provide by CMake - CPACK - useful 
> to boost.  Should boost libraries be updated to support it?
> 
> 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?
> 
> 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"?
> 
> 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
> 
> Please try to keep this discussion on this list.
> 
> I know that there has been a lot going on on slack. But having it in two 
> places makes it harder for me to review and summarize.  Also slack 
> doesn't conveniently maintain comment hierarchy.  So please try to keep 
> this discussion on this list.

I strongly suggest that the goal of using CMake with Boost begin with 
making Boost libraries, whether header-only or built, available to CMake 
projects. This also means that we have a way of testing whether or not 
such a solution actually works for any given Boost library. My own 
preference for testing whether or not such a solution would work or not 
would be to use our current b2/Boost Build test jamfiles, but if this is 
too difficult to do we still need some way to test the solution for each 
library so each library maintainer can see whether or not the solution 
we choose works for his library.

This should be our first goal and all other goals should be tabled until 
and when we can have a solution where this works flawlessly and there is 
a general agreement that whatever proposal is chosen to implement this 
is best.

Only when the above is fully accomplished should Boost then look into 
the goal of using CMake internally, perhaps for test, docs, building 
libraries, or what-not. We need to work this way because every solution 
is bound to end with comments that it does X but does not do Y or it 
does X and Y but does not do Z, and we all know where these endless 
arguments end: that we end up doing nothing because we start by trying 
to do too much and we can never reach agreement.

> 
> Robert Ramey