On 10/16/2018 3:34 AM, Alexander Grund via Boost wrote:
For Predef https://github.com/boostorg/predef/tree/develop/tools/check with documentation for usage here https://www.boost.org/doc/libs/1_68_0/doc/html/predef/check_utilities.html.
For Config https://github.com/boostorg/config/tree/develop/checks and documentation for that here https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/buil....
Thanks. Seeing this I approximate the work required to convert the checks of Config to ~1h, maybe 2h. Usage would be: include(BoostConfigFeatures) if(BOOST_FEATURE_cxx11_local_class_template_parameters) add_executable(...) endif()
Programmers are notorious for estimating the work to do any programming as about an order of magnitude less than it really takes <g>.
Some bike-shedding required: - Name for the CMake file that contains this
Anything reasonable with 'config' in the name for config and 'predef' in the name for predef.
- Naming scheme for the results of the checks (the variable in the "if")
As close as possible, using CMake naming conventions, to the name in config or predef.
- Eagerly test all or on demand:
What is the difference in CMake terms ? In Boost Build I am fairly sure the checks are done on demand, and usually involves some sort of compile/build/run/test-result cycle which would make pre-testing all checks in a library, and holding the result for further inquiry, pretty expensive.
boost_config_has(RESULT cxx11_local_class_template_parameters) if(RESULT) add_executable(...) endif()
Similar for predef: include(BoostPredefCheck) boost_predef_check(RESULT "BOOST_OS_WINDOWS != 0" "BOOST_OS_VMS != 0") if(RESULT) add_executable(...) endif()
Work is about the same and yes some checks can be omitted (e.g. boost_predef_check(RESULT "BOOST_OS_WINDOWS != 0") --> RESULT==WIN32 standard CMake variable)
Even if there is a standard CMake variable it would be worthwhile to have the check so that libraries which use the check can use the same syntax throughout.