Why is defining an unsupported variable failing the build?

Development
1

I read the idea of @craig.scott regarding the usage of CMAKE_DEFAULT_BUILD_TYPE to indicate the default build type for different generators (and not only for the “Ninja Multi-Config” generator) here.

I find it quite sensible.
Therefore, I thought I will just use this in my own project.

However, I realized quickly that defining that variable when using another generator than “Ninja Multi-Config” (e.g. “Ninja”) results in CMake failing with a hard error:

CMake Error:
  Generator

    Ninja

  does not support variable

    CMAKE_DEFAULT_BUILD_TYPE

  but it has been specified.

I would not mind if this would be an AUTHOR_WARNING that I could disable with -Wno-dev. However, this is a hard error and too much baby-sitting. (I know what I did here.)

I suggest removing this error and even extend the usage of CMAKE_DEFAULT_BUILD_TYPE to what @craig.scott suggested.

2

It is an error now because when support is implemented in other generators then it can be made not an error with those and start doing its job. If instead it just magically starts doing its job for other generators over time then it will be a silent behavior change for existing projects.

3

That sounds as if it would be a good idea to implement @craig.scott’s idea for all generators in one go and release it altogether, thereby removing the above mentioned error.

4

It is already released in 3.17 so it is too late to do it in one go. It was added late in the release cycle as part of revising the new Ninja Multi-Config generator, but that was too late to change all generators.

There are other generator-specific variables that should not be set by projects when configured by other generators. For example, the lack of errors on CMAKE_BUILD_TYPE and CMAKE_CONFIGURATION_TYPES has caused confusion.

Meanwhile it is not hard for projects to use the new variable conditionally:

if(CMAKE_GENERATOR MATCHES "Ninja Multi-Config")
  set(CMAKE_DEFAULT_BUILD_TYPE Debug)
endif()