[CMake] Debug vs Release "install" area

J Decker d3ck0r at gmail.com
Fri May 13 21:51:55 EDT 2016


there is also BUILD_TYPE (not CMAKE_BUILD_TYPE, which is the initial
condition) that often gets translated into.  BUILD_TYPE seems to get
set to the current building configuration.

http://cmake.limitpoint.com/installing-multiple-build-types-in-cmake-generated-visual-studio-projects-2/


https://cmake.org/pipermail/cmake/2011-June/044851.html
....
if(SUPPORTS_PARALLEL_BUILD_TYPE)
>>>
>>>  CMAKE_INSTALL_CONFIG_NAME is set to the current configuration name
>>> (DEbug, release, minsizerel) as chosen in the visual studio
>>> environment.... so to choose which you build - you choose which you
>>> build.
>>>
>>> It doesn't package multiple configurations at once into a single NSIS,
>>> but it will package any single configuration.





On Fri, May 13, 2016 at 1:43 PM, Roman Wüger <roman.wueger at gmx.at> wrote:
> You could use conditional generator expressions e.g $<CONFIG> with a
> combination of add_custom_command stuff like "${CMAKE_COMMAND} -P
> yourscript.cmake " to handle the rest.
>
> Best Regards
> Roman
>
> Am 12.05.2016 um 22:07 schrieb Scott Aron Bloom <scott at towel42.com>:
>
> Looking for some advice.
>
>
>
> In order to make our Visual Studio debugging environment, as self-contained
> (and easy to use for the developers) as possible, we use developers must run
> an install.  We also use the resulting release based Install for our
> packaging into our installer.
>
>
>
> We change the prefix variable CMAKE_INSTALL_PREFIX, to
> ${CMAKE_BINARY_DIR}/Install, as well as having a each application call a
> function that places a .user.vcxproj that sets the PATH appropriately.
>
>
>
> It really works great, except there is one caveat.  VC++ has libraries that
> are debug vs release dependent, so if your debug build happens to pick up a
> release DLL (or vice versa) you can (will) be in trouble in random ways.
>
>
>
> Typically, when I change over, I simply delete the install, and re-install.
>
>
>
> Ideally, I would like to know is there any way to set the
> CMAKE_INSTALL_PREFIX variable separately for debug vs release? If so how?
>
>
>
> A second option, which I thought of…
>
>
>
> Is to generate a file “DEBUG.BUILD.TXT” and then at the START of the
> installation process, run a script for debug builds, that says if the file
> doesn’t exist, delete everything and carry on.  If running for a release
> install, if it DOES exist delete and carry on.
>
>
>
>
>
> Any thoughts on this?
>
> Thanks
>
>
> Scott
>
>
>
>
>
> --
>
> 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
>
>
> --
>
> 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


More information about the CMake mailing list