Add option to set CMAKE_BUILD_TYPE also on multi config generators #1393
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes behavior
This PR add the option to set
CMAKE_BUILD_TYPE
when a multi config generator likeVisual Studio
is set. I've add a new option namedcmake.setBuildTypeOnMultiConfig
.true
: theCMAKE_BUILD_TYPE
will be set in multi config generatorsfalse
(default): theCMAKE_BUILD_TYPE
wont be set in multi config generatorsSo the merge of that PR wont change anything for existing users!
The purpose of this change
I know many projects which use
CMAKE_BUILD_TYPE
to force single config also on multi config generators, including myself 😄 . A example-code for that would beI see that often when you have a project with multi platform support, were single config generators are the typical use. I used multi config generators like
Visual Studio
for years, but because it does only add complexity to a project without any real benefit (in CI it is much slower because we have to clone always all config and such kind of problems) I completely get rid of it with the above technique after looking into many bigger open source projects which using cmake and using these technique. I know that this is not the "normal" case in multi config generators since cmake 3.0, so this is some kind of personal preference.The problem
The problem is that the build type choosed in the vscode menu is most of the time not in sync with the configured on when some project use the technique as above. This leads to some kind of problems when for example starting the
cmake build
command with f.e. useDebug
during configure but in the vscode menu it isRelease
and so I get an error with theVisual Studio
generator because the command line looks likecmake --build . --config Release
but the config does not exists (thanks to setting CMAKE_CONFIGURATION_TYPES to a single value).To be able to set the
CMAKE_BUILD_TYPE
is always have to set it in thesettings.json
file, which works, but it leads to the build type not in sync problem pretty fast.The solution
By just adding this new option, cmake tools can behave like it do until now, but if someone like me has projects with this type of
CMAKE_BUILD_TYPE
handling the user can just active support for it (in workspace or globally) and that without any kind of risk as far as I can tell. After activating this the user can change the build type normally via the vscode menu from cmake tools.Greetings
Tonka