Boost logo

Boost :

Subject: Re: [boost] Boost CMake support - Request for Comment
From: Roger Leigh (rleigh_at_[hidden])
Date: 2018-10-15 20:36:35

On 10/10/18 15:23, Edward Diener via Boost wrote:
> On 10/10/2018 4:44 AM, Roger Leigh via Boost wrote:
>> This is all supported by CMake for years as mike said, and it's
>> utterly trivial to write such feature tests.  If you would like some
>> examples, here's some I wrote for Xerces-C++:


>> I don't think any of this is difficult.  If anything, you can likely
>> reuse the existing source code used by the Boost.Build checks, maybe
>> even sourced directly without any changes--just wrap it with
>> check_cxx_source_compiles or other feature test macros.
> My point is that you can not ask each library maintainer to re-invent
> what he already uses from Boost config and/or Boost predef. You need to
> reprogram this in CMake for each case in config and predef, and then
> provide a CMake-like interface to it for other libraries. I do not care
> how easy you find it in CMake, individual library maintainers are not
> going to spend time re-duplicating everything they need from config and
> predef just so they can build their library and/or run their library
> tests. We are talking about some 130+ potential Boost libraries we have
> to deal with, and any conversion to CMake that is non-trivial is going
> to be very unpopular.

The logic could be written to be either in a single place (which can
provide CMake logic for other components to use), or duplicated in the
different components. Which is better depends upon how decoupled you
wish the components to be. If you always require a monolithic build,
then one component could provide shared functionality. Otherwise,
duplication is better to avoid tight coupling. As an example:

are modules I routinely share between related components of a larger
project. Not the size of Boost though.

I looked at the Boost config and predef links Rene provided in another
email in this thread.

The Boost.Config checks all look pretty straightforward. Should be
possible to iterate over them and store each one in a variable, then we
could provide them in the exported configuration for dependent
components to consume.

(While I see this component does have CMake support merged in, I don't
see any configuration export. Where is that handled? Has anyone worked
on it yet?)

For Boost predef this isn't much different; run the program and store
the results, export the variables.

In both cases, CMake users can then simply run conditional logic such as:

   if (boost_feature)
     list(APPEND sources foo.cpp)


   if (boost_feature2 AND boost_feature3 AND NOT boost_feature 4)
      add_executable(foo …)

and so on.

Note that a number of the predef checks are already supported directly
by CMake, such as
etc. While the predef checks can be carried over for completeness, they
are not necessary.

I would be happy to work on some of this. I'm not sure exactly how to
do so however. Where would I submit it? Is CMake development
discussion happening on any other lists or other places? I don't want
to tread on any toes or work at cross-purposes.


Boost list run by bdawes at, gregod at, cpdaniel at, john at