Subject: [boost] [cmake] Pull request announcement
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-09-14 11:44:49
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
- 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
- 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
- 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.