[CMake] Is there any way to set a build-type specific install path for multiconfig tools?

[David Cole]

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 <cliffyapp at gmail.com> wrote:
> On Mon, Jul 13, 2015 at 1:45 PM, David Cole <DLRdave at 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