[boost] [cmake] Pull request announcement

Subject: [boost] [cmake] Pull request announcement
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-09-14 11:44:49

Dear all,

unless I'm encountering an overwhelming resistance to this idea 
here on the ml, I intend to create a batch of PRs that introduce 
minimal cmake support to a large subset of boost libraries 
(maybe even all).

It appears that cmake efforts have yet again stalled. 
Last I heard was that everyone is waiting for BCM and 
the author of that library still tries to find a review manager. 
As we probably can't expect a full-fledged, boost-wide solution 
in the near future I'm trying it with a low-effort 
approach that will establish the minimal framework needed such 
that each library can be (where necessary) build with cmake 
and specify it's dependencies on other libraries (the latter 
being the really important part). 
>From that starting point a more holistic solution can then be 
developed step by step and (in most cases) library by library.

The only fundamental thing that needs to be decided by the 
community is a canonical naming scheme for the cmake targets 
that should be used by other libraries in their 
`target_link_libraries` call. For that I suggest that each 
library should provide an alias target called

        Boost::<library_name> (e.g. Boost::program_options)

This also follows the naming scheme provided by cmake itself when 
using boost libraries that are installed on the system.

Now about what I'm specifically going to put into the PRs:

- I'll propose a trivial, top-level cmake file be added 
  to the boost super project that doesn't do anything but 
  look for CMakeLists.txt files in the root folder of each 
  library and calls that file if present

- Individual libraries get a simple CMakeLists.txt file 
  that will
        - create an appropriate build target 
                - INTERFACE library for header-only 
                - STATIC for regular libraries
        - create an alias named Boost::<library_name> 
        - build the library if necessary
        - specifying the minimum required c++ version
        - specify the local include directory 
       (iirc that will always be "include")
        - specify all required dependencies 

This will not address 
        - Testing
        - Installation
        - Creation of shared libraries
        - Creation of documentation
        - Special provisions for IDE integration

In short: all the difficult stuff is left out ;) 
The goal is not to present a solution that can replace b2 but to have 
a minimal starting point upon which individual library authors or the 
community as a whole can make iterative improvements. If and when BCM 
(or an alternative) is accepted into boost, individual libraries can 
then easily switch to this full-fledged solution and of course any 
author can create a more complete CMake solution for his library at 
any time (as some already have). 

Finally, please don't nick-pick this to death. 
I'd like to have a more complete solution too, but it isn't 
coming, so let's do the minimum we can and go on from there. 
Note that the advantage of such a minimal solution is also that 
there are very few design decisions to make that may later turn 
out to be wrong and then create a maintenance burden.

The only things that are visible on an interface level 
(and thus should remain reasonable stable) are:

- The alias name Boost::<library_name>

- How the public dependencies are specified: 
  target_link_libraries( boost_ foo 
        PUBLIC 
                Boost::config 
                Boost::core 
                Boost::bar
  ) 

- The position of the CMakeLists.txt file in the library root folder

All of this is long established best practice. 
Anything else can gradually be built on top of that.

Best

Michael