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:41:52

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
> <boost_at_[hidden]> 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/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 ?
> 
> 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.