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

Subject: Re: [boost] Boost CMake support - Request for Comment
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-10-15 20:50:54

On 10/15/2018 4:36 PM, Roger Leigh via Boost wrote:
> 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.

Nearly every library depends on Boost.Config. Boost.Predef was created 
much, much later than Boost.Config so I do not know how many libraries 
use its functionality.

Creating support for Boost.Config check builds should be done once in 
Boost.Config and creating support Boost.Predef check builds should be 
done once in Boost.Predef. Expecting individual libraries to duplicate 
what is current in those libraries, for CMake, is not something the 
maintainers of those other libraries will want to do.

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

It would be best to mention that you would like to help convert the 
check builds functionality in those two libraries to CMake on the 
appropriate library's Github page. You could bring this up as Issues for 
each of the two libraries and eventually create PRs.

> 
> 
> Regards,
> Roger