Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build types #19

Open
ruslo opened this issue Mar 26, 2017 · 4 comments
Open

Build types #19

ruslo opened this issue Mar 26, 2017 · 4 comments

Comments

@ruslo
Copy link
Owner

ruslo commented Mar 26, 2017

@Knitschi
Copy link

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.

@ruslo
Copy link
Owner Author

ruslo commented Jul 27, 2017

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_ 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:

@Knitschi
Copy link

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?

@ruslo
Copy link
Owner Author

ruslo commented Jul 27, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants