Most of the variables that have a per-config variation on the name end with "_<CONFIG>" ( see the page documenting CMake variables, and search it for "config" to get a sense of which variables these are... http://www.cmake.org/cmake/help/v3.3/manual/cmake-variables.7.html ) -- soooo, if you do prepare any patches for consideration, I would say use "CMAKE_INSTALL_PREFIX_<CONFIG>" as the names of the alternate variables.
I don't know what the consensus opinion will be, but I think CMAKE_INSTALL_PREFIX is already difficult to understand fully as-is, and I would hesitate to add per-config complexity to it. I am certain there are others with different opinions on the matter, though. We'll see if anybody else chimes in. D On Tue, Jul 14, 2015 at 7:52 AM, Clifford Yapp <cliffy...@gmail.com> wrote: > On Mon, Jul 13, 2015 at 1:45 PM, David Cole <dlrd...@aol.com> wrote: > >> The other "no need to modify CMake" way to achieve this (although it >> may be considered "too ugly" or non-ideal by some) would be to force >> the use of a single configuration per build tree, and use the proper >> value for CMAKE_INSTALL_PREFIX in each build tree. >> >> Your developers may not like that, but it would sure make the problem >> at hand disappear. > > It would, but I think I would agree that's a fairly ugly solution - at > least, it violates assumptions a dev might reasonably make in the > multi-config workflow. What I have in place now does the job and > works (or at least, it did the last time I tried it) so I can stick > with it if need be, but I figured it was worth raising the question to > see if there either already existed a cleaner way or there was a way > to add a "clean" way that would be acceptable to the devs. > >> The other thing to consider is that the file cmake_install.cmake, >> generated at the top of your build tree contains code like the >> following: >> >> # Set the install prefix >> if(NOT DEFINED CMAKE_INSTALL_PREFIX) >> set(CMAKE_INSTALL_PREFIX "C:/Program Files (x86)/Tutorial") >> endif() >> >> In the end, installing your project is ultimately a call of some sort >> to "cmake -P cmake_install.cmake" -- you could simply install your >> project with a custom call to that script which passes in the proper >> value for CMAKE_INSTALL_PREFIX using -D... The above generated code >> allows you to override it by passing it in when the script is called. >> >> The Visual Studio command for the INSTALL project looks like this: >> >> "C:\Program Files (x86)\CMake\bin\cmake.exe" >> -DBUILD_TYPE=$(Configuration) -P cmake_install.cmake >> >> You could easily write a custom target / custom command that is an >> alternate "configuration-prefixed" install as: >> >> "C:\Program Files (x86)\CMake\bin\cmake.exe" >> -DBUILD_TYPE=$(Configuration) >> -DCMAKE_INSTALL_PREFIX=config-specific-value-here -P >> cmake_install.cmake > > Can that bit of code be controlled from the CMakeLists.txt file, or > would I need to manually overwrite it in some fashion after it is > generated? > > If a patch were prepared to use variables like > CMAKE_DEBUG_INSTALL_PREFIX, would the devs consider it? That still > feels to me like it's probably the "right" solution given how CMake > handles this for things like C flags, unless it causes too many other > problems... > > Thanks, > CY -- 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
