CGold icon indicating copy to clipboard operation
CGold copied to clipboard

Build types

Open ruslo opened this issue 7 years ago • 4 comments

  • http://stackoverflow.com/a/28124715/2288008
  • https://gitlab.kitware.com/cmake/cmake/merge_requests/591#note_244652

ruslo avatar Mar 26 '17 06:03 ruslo

Hi ruslo, first of all cudos for this great project. A cmake documentation that provides a better overview and the greater picture of cmake is really needed.

I am currently struggeling in my project with this topic so I just wanted to stop by and upvote this issue.

I am confused about how things should be handled when using single config generators. Should in this case CMAKE_BUILD_TYPE be manually set? Should I use the config dependend properties like LIBRARY_OUTPUT_NAME_<CONFIG> or the non config version LIBRARY_OUTPUT_NAME.

For example I observed that the imported targets of the Qt hunter package use the config ${suffix} for some properties, but not for others. The cmake documentation itself is very thin about the intent of these property names and when we should use which.

Maybe you can shed some light on this when you find the time to work on this section.

Knitschi avatar Jul 27 '17 08:07 Knitschi

Should in this case CMAKE_BUILD_TYPE be manually set?

If you're using single-configuration generator you should use this variable on generating stage:

> cmake -H. -B_builds -DCMAKE_BUILD_TYPE=Release

However your code should be designed to work with all types of generators, i.e. you should not check CMAKE_BUILD_TYPE in CMakeLists.txt since it makes no sense for multi-configuration generators.

Should I use the config dependend properties like LIBRARY_OUTPUT_NAME_<CONFIG> or the non config version LIBRARY_OUTPUT_NAME

Depends on the goal, I guess if you library name differs for different Release/Debug config, then you can modify LIBRARY_OUTPUT_NAME_<CONFIG>. Note that you can use CMAKE_*_POSTFIX if you want all variants of library installed to the same root directory:

  • https://github.com/ruslo/hunter/blob/382aec18eba519d49c34491106a8e125cbc035e0/cmake/schemes/url_sha1_cmake.cmake.in#L106

ruslo avatar Jul 27 '17 14:07 ruslo

Ok, good to know. But what can go wrong if I do not define CMAKE_BUILD_TYPE? Why is it not set to Release by default?

So can I say that whenever there is a property that has a config neutral version, it is supposed to be the default value of that property and the config specific versions will override that value?

Knitschi avatar Jul 27 '17 17:07 Knitschi

But what can go wrong if I do not define CMAKE_BUILD_TYPE?

Nothing, you will not have neither optimization nor debug flags. It's a valid build still though.

Why is it not set to Release by default?

Default value can be set to cache I guess but note that it will not be used by multi-configuration generators:

set(CMAKE_BUILD_TYPE "Release" CACHE STRING "Build type")

So can I say that whenever there is a property that has a config neutral version, it is supposed to be the default value of that property and the config specific versions will override that value?

I think if you match exactly then _<CONFIG> property will be used, if it doesn't match, then default will be used. Also you can map missing variants: https://cmake.org/cmake/help/latest/variable/CMAKE_MAP_IMPORTED_CONFIG_CONFIG.html

What is the exact case for you now? Why do you need to manipulate these properties? In most cases it's not needed.

ruslo avatar Jul 27 '17 17:07 ruslo