Menu
Specifies the build type on single-configuration generators. This statically specifies what build type (configuration) will be built in this build tree. Possible values are empty, Debug , Release , RelWithDebInfo and MinSizeRel .
CMakeLists. txt file contains a set of directives and instructions describing the project's source files and targets (executable, library, or both). When you create a new project, CLion generates CMakeLists. txt file automatically and places it in the project root directory.
CMake is a meta build system that uses scripts called CMakeLists to generate build files for a specific environment (for example, makefiles on Unix machines). When you create a new CMake project in CLion, a CMakeLists. txt file is automatically generated under the project root.
exerpt: "RelwithDebInfo is quite similar to Release mode. It produces fully optimized code, but also builds the program database, and inserts debug line information to give a debugger a good chance at guessing where in the code you are at any time."
There are two types of generators: single-configurations and multi-configurations.
Make-like generators: Unix Makefiles, NMake Makefiles, MinGW Makefiles, ...
You set the configuration type in the generate step:
cmake -H. -B_builds/Debug -DCMAKE_BUILD_TYPE=Debug "-GUnix Makefiles"
In this case, the build step is always Debug:
> cmake --build _builds/Debug
/usr/bin/c++ -g ...
> cmake --build _builds/Debug --config Debug # `--config` ignored
/usr/bin/c++ -g ...
> cmake --build _builds/Debug --config Release # yep, ignored
/usr/bin/c++ -g ...
IDE generators: Visual Studio, Xcode
CMAKE_BUILD_TYPE on generate step is ignored, both:
> cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Debug "-GVisual Studio 12 2013 Win64"
and
> cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Release "-GVisual Studio 12 2013 Win64"
will have the same effect:
This is because all the configurations is internal (i.e., _builds/msvc-opaque/Release and _builds/msvc-opaque/Debug or something, doesn't matter). You can use --config options to switch:
> cmake --build _builds --config Release
cl /O2 ...
> cmake --build _builds --config Debug
cl /Od ...
Yes, you can. Just define CMAKE_CONFIGURATION_TYPES:
# Somewhere in CMakeLists.txt
message("Generated with config types: ${CMAKE_CONFIGURATION_TYPES}")
Default output:
-- Detecting CXX compiler ABI info - done
Generated with config types: Debug;Release;MinSizeRel;RelWithDebInfo
-- Configuring done
Rewrite it:
> cmake -H. -B_builds -DCMAKE_CONFIGURATION_TYPES="Debug;Release" "-GVisual Studio 12 2013 Win64"
-- Detecting CXX compiler ABI info - done
Generated with config types: Debug;Release
-- Configuring done
You can even define your own configuration type:
> cmake -H. -B_builds -DCMAKE_CONFIGURATION_TYPES="Debug;MyRelease" -DCMAKE_CXX_FLAGS_MYRELEASE="/My-Rel-flag" -DCMAKE_EXE_LINKER_FLAGS_MYRELEASE="/My-Linker-flags" "-GVisual Studio 12 2013 Win64"
And build:
cmake --build _builds --config MyRelease
Not at all if you know the trick :) This is how to build/test configuration in a script/CI server/documentation's build instructions, etc.:
> CONFIG=Debug
> cmake -H. -B_builds "-DCMAKE_BUILD_TYPE=${CONFIG}" # Set Debug to Makefile, ignored by IDE
> cmake --build _builds --config "${CONFIG}" # Build Debug in IDE, ignored by Makefile
> (cd _builds && ctest -VV -C "${CONFIG}") # Test Debug in IDE, ignored by Makefile
if(CMAKE_BUILD_TYPE STREQUAL Debug) # Burn it with fire!!!
set(CMAKE_BUILD_TYPE MySuperRelease) # Be ready to catch a bug from IDE user...
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} --my-debug-flags")
Works nice.
target_compile_definitions(MyTarget PUBLIC "$<$<CONFIG:Debug>:MYDEBUG_MACRO>")
Thank you! :) You save a day for one programmer.
Some quote from a nice book of a nice guy you probably know (emphasis mine):
Why should you bother? People who program on a variety of systems or use a variety of compilers care a lot because if they don’t, they are forced to waste time finding and fixing obscure bugs. People who claim they don’t care about portability usually do so because they use only a single system and feel they can afford the attitude that ‘‘the language is what my compiler implements.’’ This is a narrow and shortsighted view. If your program is a success, it is likely to be ported, so someone will have to find and fix problems related to implementation dependent features. In addition, programs often need to be compiled with other compilers for the same system, and even a future release of your favorite compiler may do some things differently from the current one. It is far easier to know and limit the impact of implementation dependencies when a program is written than to try to untangle the mess afterwards.
You can also use following snippet:
if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING
"Default build type: RelWithDebInfo" FORCE)
endif()
One possibility that occurs is that one of the sub-modules had set the CMAKE_BUILD_TYPE value in the cache, that is:
SET(CMAKE_BUILD_TYPE Debug CACHE)
Meaning that that value will be updated permanently from that point to the end of the configuration run.
One great way to track the offending place where this value has changed is by using CMake's variable_watch. In your main CMakelists.txt file, add the following line
variable_watch(CMAKE_BUILD_TYPE)
This will print to the standard error every access to this variable. And to get it to log file, do something like:
cmake <your options> 2>variable_watch.log
You may see something like:
CMake Debug Log at <...>/CMakeLists.txt:184 (add_library): Variable "CMAKE_BUILD_TYPE" was accessed using READ_ACCESS with value "Debug".
Then you will likely see the point(s) where CMAKE_BUILD_TYPE was first changed. And from here you'll be much closer to trace the offending CMake line.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With