"Modern" approach to optional/multiple configurations?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

"Modern" approach to optional/multiple configurations?

Nicholas Devenish
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

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "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:

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 <[hidden email]> 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

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Modern" approach to optional/multiple configurations?

CMake mailing list
In reply to this post by Nicholas Devenish
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.



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Loading...