[CMake] What is the default build type?

[J Decker]

On Wed, Aug 2, 2017 at 11:50 AM, David Cole via CMake <cmake at cmake.org>
wrote:

> Yes, your code is a good example Marcus. It was one of the previous
> suggestions on this thread which had example code setting
> CMAKE_CONFIGURATION_TYPES.
>
> I would recommend against setting this variable because in some places
> in CMake code, it is used as an approximate proxy for whether or not a
> multi-configuration generator is being used.
>
>
> For a few examples, see the CMake code base itself:
>
> MinGW Makefiles supports multiple configurations; one at a time.  And
reading a few of these...


> $ git grep CMAKE_CONFIGURATION_TYPES | grep -Ev
> "Auxiliary/vim/syntax/cmake.vim|Help/|Tests/"

CMakeCPack.cmake:  if(CMAKE_CONFIGURATION_TYPES)
>
this one is not distributed, and I don't have it.


> Modules/CMakeExpandImportedTargets.cmake:#
> ${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}.
> Modules/CMakeExpandImportedTargets.cmake:
> if(CMAKE_CONFIGURATION_TYPES)
> Modules/CMakeExpandImportedTargets.cmake:         list(GET
> CMAKE_CONFIGURATION_TYPES 0 CEIT_CONFIGURATION)
>

the whole point is to get a good setting list for CMAKE_BUILD TYPE so this
is harmless because built type will override the default behavior...
# CONFIGURATION is given, it uses the first configuration from
# ${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}.



> Modules/CTestTargets.cmake:if(CMAKE_CONFIGURATION_TYPES)
>

I would want this to pass CONFIGURATION_TYPES to included external projects
because it's missing otherwise anyway.


> Modules/DeployQt4.cmake:                        if(configurations AND
> (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE))
> Modules/DeployQt4.cmake:                if(CMAKE_CONFIGURATION_TYPES
> OR CMAKE_BUILD_TYPE)
>

This is used to use the argument passed to the macro if CMAKE_BUILD_TYPE
(this is what we want set anyway) OR CMAKE_CONFIGUATION_TYPES is set.


> Modules/ExternalProject.cmake:      if(CMAKE_CONFIGURATION_TYPES)
> Modules/ExternalProject.cmake:        if(CMAKE_CONFIGURATION_TYPES)
> Modules/ExternalProject.cmake:  if(CMAKE_CONFIGURATION_TYPES)
> Modules/ExternalProject.cmake:    if(CMAKE_CONFIGURATION_TYPES)
> Modules/ExternalProject.cmake:      foreach(cfg
> ${CMAKE_CONFIGURATION_TYPES})
>

In these cases, it makes sure to pass the build configuration passed from
the core project, otherwise it leaves it blank.  Since I want to specify
the build configuration anyway, this should always be set if
externalproject is  used.


> Modules/FindBoost.cmake:      if(CMAKE_CONFIGURATION_TYPES OR
> CMAKE_BUILD_TYPE)
>

if neither of these are set it sets release output.  and we're trying to
make sure that CMAKE_BUILD_TYPE is set to something not blank anyway.


> Modules/FindCUDA.cmake:# Makefile and similar generators don't define
> CMAKE_CONFIGURATION_TYPES, so we
> Modules/FindCUDA.cmake:set(CUDA_configuration_types
> ${CMAKE_CONFIGURATION_TYPES} ${CMAKE_BUILD_TYPE} Debug MinSizeRel
> Release RelWithDebInfo)
>

This one includes already set configuration types, and add capitalized
versions; then builds a list and removes duplicate because it sets all
configurations to UPPER(); so this is harmless.  and is a better
implementation than the below SelectLibraryConfigurations.cmake:

(comment block in FindCUDA)
# Makefile and similar generators don't define CMAKE_CONFIGURATION_TYPES,
so we
# need to add another entry for the CMAKE_BUILD_TYPE.  We also need to add
the
# standerd set of 4 build types (Debug, MinSizeRel, Release, and
RelWithDebInfo)
# for completeness.  We need run this loop in order to accomodate the
addition
# of extra configuration types.  Duplicate entries will be removed by
# REMOVE_DUPLICATES.

...and yet they[makefile and similar] should have configuration types;
because they can build all of those configurations.




> Modules/FindQt4.cmake:        if (CMAKE_CONFIGURATION_TYPES OR
> CMAKE_BUILD_TYPE)
>


again- cmake_build_type is being set, so don't default to Release



> Modules/SelectLibraryConfigurations.cmake:           (
> CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE ) )
>

Would be triggered because we're setting CMAKE_BUILD_TYPE anyway..; and
also does not support minreldebinfo or MinSizeRel; and instead only checks
_DEBUG and _RELEASE targets.



> Source/cmGlobalVisualStudio7Generator.cxx:  if
> (!mf->GetDefinition("CMAKE_CONFIGURATION_TYPES")) {
> Source/cmGlobalVisualStudio7Generator.cxx:
> "CMAKE_CONFIGURATION_TYPES",
> "Debug;Release;MinSizeRel;RelWithDebInfo",

Source/cmGlobalXCodeGenerator.cxx:  if
> (!mf->GetDefinition("CMAKE_CONFIGURATION_TYPES")) {
> Source/cmGlobalXCodeGenerator.cxx:      "CMAKE_CONFIGURATION_TYPES",
> "Debug;Release;MinSizeRel;RelWithDebInfo",
> Source/cmGlobalXCodeGenerator.cxx:
> this->CurrentMakefile->GetRequiredDefinition("CMAKE_CONFIGURATION_TYPES");
> Source/cmMakefile.cxx:
> this->GetDefinition("CMAKE_CONFIGURATION_TYPES")) {
> Utilities/Release/WiX/CMakeLists.txt:if(CMAKE_CONFIGURATION_TYPES)
>

These would be used, and would set cmake_configuration_types so we don't
have to; they set it, not use it.


So, all in all, it looks like it is either indifferent to being set, or
SHOULD be set to make sure configuration types are propagate
(externalProject).


I asked a LONG time ago why this wasn't set by default anyway, and was told
'because makefiles'... and yet I built all sortf of projects using makefile
generators and found that I HAD to get this set anyway because I was
building Debug and Release modes continuously there (one so I could debug,
the other so I could test optimal); otherwise the output behavior was
inconsistent and would overlap release and debug configuration builds.  I
subsequently fixed THAT by making sure to build in .../build/debug_projects
and output to ../build/debug_out (install target) and
..../build/release_projects and .../build/release_out so iteritive building
wouldn't get mixed debug and release objects trying to build into a
library/executable.


>
>
>
>
> On Wed, Aug 2, 2017 at 2:42 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
> > On Wed, Aug 2, 2017 at 1:32 PM, David Cole <DLRdave at aol.com> wrote:
> >> Very cool, Marcus. Thanks for the blog post.
> >>
> >> Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty
> >> because you are using a single-configuration CMake generator. Only
> >> Visual Studio and Xcode (and possibly other) **multi** config
> >> generators have a list of values in CMAKE_CONFIGURATION_TYPES.
> >> Contrary to the previous recommendation, I would NOT recommend setting
> >> it to a list in a single configuration generator. If you're using a
> >> multi-config generator, you can set up a subset for it to use with
> >> this, but in a single config generator, this variable SHOULD be empty,
> >> and you should not give it contents in that case.
> >>
> > Terrible English, try number two... Why would you not recommend
> > setting it, and what do you mean by it? I was not setting
> > CMAKE_CONFIGURATION_TYPES to anything, but the CMAKE_BUILD_TYPE
> > property is manipulated to offer the list, and then the
> > CMAKE_BUILD_TYPE variable is populated if it is empty in my example.
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170802/99ed9847/attachment-0001.html>