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

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++:
 >>

[examples]

>>
>> 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:

   https://gitlab.com/rleigh/ome-common-cpp/tree/master/cmake

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)
   endif()

or

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

and so on.

Note that a number of the predef checks are already supported directly 
by CMake, such as
   if(MSVC)
   if(WIN32)
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.

Regards,
Roger