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

[paul]

On Mon, 2017-07-24 at 10:46 +0100, Nicholas Devenish 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).

At least Daniel Pfeifer's presentation of best practices here:

https://www.slideshare.net/DanielPfeifer1/cmake-48475415

Says:

* Dont’t make libraries STATIC/SHARED unless they cannot be built otherwise.
* Leave the control of BUILD_SHARED_LIBS to your clients!

Which would imply a build tree per configuration. I have never seen any
information of best practices that suggests creating multiple targets for each
variant in cmake 2 or 3.