[CMake] "Modern" approach to optional/multiple configurations?

[Nicholas Devenish]

Hi Again,

I was asked to link to the background discussion for this (good point!).
The actual post was:
    https://lists.boost.org/Archives/boost/2017/07/237490.php

and there's quite a bit of talk in that thread and a few similarly-named
others about CMake. This announcement seems to have stirred up some old/new
controversies, and I'm pretty sure there is a decent amount of
misunderstanding/old assumptions about CMake.

I was just rather taken back by this statement because I've been trying to
research "Modern" CMake and hadn't encountered anything like this. Perhaps
I'm merely imagining something wildly different from the intention.

Nick


On Mon, Jul 24, 2017 at 7:46 PM, Nicholas Devenish <ndevenish at gmail.com>
> wrote:
>
>> Seen in the boost discussions on the CMake announcements:
>>
>>
>>> > The rest can be implemented straightforwardly as cache options so that
>>> > you can run cmake with options like
>>> >
>>> >   -Dvalgrind=OFF -Dtransactional-memory=ON -Dsegmented-stacks=ON [-D…]
>>> ...
>>
>> Secondly, in cmake 3 we try not to configure things using -D as we did
>>> in cmake 2. Instead we make targets customised for that build
>>> combination. The user then chooses to make or link to those targets if
>>> they want those targets.
>>>
>>
>> Is this true, and is there a good example of a project with such a
>> configuration?
>>
>> I've been trying to learn the more modern approaches to writing
>> CMakeLists recently, and haven't come across such advice - I was under the
>> impression that cache-set options (that the build can make decisions on)
>> was still the recommended 'clean' way, and then options (and even extra
>> sources, dependencies) can be added to each target as required.
>>
>> As I imagine what this is saying, It seems that target-per-configuration
>> would just lead to an explosion of duplicated targets and duplicated code,
>> especially through every permutation of several different options?
>>
>> Part of the niceness of target-oriented dependencies was just having one
>> thing to link to and depending on the configuration, that target would be
>> the correct one (and pass through it's configuration).
>>
>> Nick
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170724/c257a4a6/attachment.html>