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/buil... 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.ru... 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.cm...
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.