[boost] Boost CMake support - Request for Comment

Subject: [boost] Boost CMake support - Request for Comment
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-01 17:07:14

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.

Robert Ramey