On 10/9/2018 7:58 PM, Andrey Semashev via Boost wrote:
On Wed, Oct 10, 2018 at 2:43 AM Edward Diener via Boost
wrote: 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?
I do not think what you propose. I am just pointing out that this feature, used extensively from config and/or predef for a number of Boost libraries, needs to have an equally easy CMake equivalent so that converting the library's build or test jamfile to CMake is fairly trivial.
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.