On Wed, Oct 10, 2018 at 2:43 AM Edward Diener via Boost
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 ?
Why do you think a potential Boost.CMake proposal cannot offer an equivalent of check-target-builds that internally uses the checks based on Boost.Config or Boost.Predef? Because, AFAIU, check-target-builds is exactly that - a compile test that involves a preprocessor check of one of the macros + a bit of caching on Boost.Build side. Doesn't sound like something that can't be done in CMake. As for the conversion process, I don't think it is reasonable to expect a single person, a Boost.CMake candidate author, to convert all Boost Jamfiles to CMake. Library authors *will* have to learn the new build system and do the conversion of their libraries. Hopefully, a proposed Boost.CMake should make it easier, but it won't be a free ride. PS: Also, let's not over-quote, please.