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
