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-10 14:23:12

On 10/10/2018 4:44 AM, Roger Leigh via Boost wrote:
> On 09/10/2018 23:42, Edward Diener via Boost wrote:
>> On 10/9/2018 7:09 PM, mike via Boost wrote:
> 
>>> As Richard pointed out, such features exist in cmake too and have 
>>> been in
>>> common use for years. E.g. It has a built-in mechanism that lets you
>>> directly query for most of the post c++03 compiler features:
>>> (https://cmake.org/cmake/help/v3.13/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html) 
>>>
>>> and as a more general feature, you can always check if a particular 
>>> source
>>> file using some feature or type compiles or not:
>>> (https://cmake.org/cmake/help/v3.13/module/CheckCXXSourceCompiles.html)
>>>
>>> Could you maybe point me to some examples where this feature is used 
>>> so one
>>> could estimate how difficult a conversion is?
>>
>> The feature is essentially programmed by config and predef to provide 
>> build-time testing of compiler support and testing of such things like 
>> the OS versions and compiler versions etc. See 
>> https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/build_config.html 
>> for the explanation in config and 
>> https://www.boost.org/doc/libs/1_68_0/doc/html/predef/check_utilities.html 
>> for checking predef values at build time. The basics of the feature 
>> are offered by Boost Build as explained at 
>> https://boostorg.github.io/build/manual/develop/index.html#bbv2.reference.rules 
>> in reference to the check-target-builds rule. Plenty of libraries use 
>> the feature during testing and I imagine that some of them may use the 
>> feature during building. Asking individual libraries to convert their 
>> tests or build to use some CMake equivalent, for every possible 
>> setting in config and predef which they use, is not realistic. I 
>> understand that CMake may have an equivalent technique, but who is 
>> going to program that technique to offer all the equivalents which 
>> config and predef currently offer ?
> 
> 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++:
> 
> https://github.com/apache/xerces-c/tree/trunk/cmake
> 
> For example, here's a simple test for const [it's a port of Autoconf 
> logic] with CheckCXXSourceCompiles:
>  Â  https://github.com/apache/xerces-c/blob/trunk/cmake/XercesConst.cmake
> this could be adapted for any feature you care to check, from constexpr 
> to user-defined literals, or any other feature which can be checked by 
> running the compiler.
> 
> This is a set of checks for integer type sizes: 
> https://github.com/apache/xerces-c/blob/trunk/cmake/XercesIntTypes.cmake
> 
> This is a more complex set of checks for SSE intrinsics: 
> https://github.com/apache/xerces-c/blob/trunk/cmake/XercesSSE2.cmake
> 
> Here's some checks to verify Boost is working properly:
> https://gitlab.com/codelibre/ome-common-cpp/blob/master/cmake/BoostChecks.cmake 
> 
> 
> Testing of linker version scripts: 
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L198
> 
> Checking include presence: 
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L212
> 
> Checking compiler keyword presence and fallbacks: 
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L226
> 
> Checking structure presence: 
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L226
> 
> Checking library symbol exports: 
> https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L226
> 
> 
> 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.