Setting CMAKE_BUILD_TYPE to None is incorrect. You are saying you want to use a custom build type that is literally called None. Since you define no variables for this custom None build type, it may coincidentally behave similar to CMAKE_BUILD_TYPE being unset or set to an empty string, but there may be corner cases where that isn’t so. The output you showed earlier with this value None is really just trying to tell you that CMAKE_BUILD_TYPE holds an empty string.
Setting CMAKE_CONFIGURATION_TYPES for a single config generator should be meaningless, don’t do it.
If you truly want the effect of getting CMAKE_CXX_FLAGS but none of the other CMAKE_CXX_FLAGS_<CONFIG> flags, then setting CMAKE_BUILD_TYPE to an empty string would achieve that. But as the docs say, that is almost never what a developer wants. I would question the use case where you don’t want any configuration, but you haven’t given any detail why you want that specific behavior. If you were using a multi-config generator, you don’t have the choice of an empty configuration. Being able to use one for single configuration generators is a bit of an anomaly.
We build many 3rd party dependencies that already have cmake builds, but we use bazel with a bazel cmake wrapper. We have also defined our own custom bazel gcc toolchain, and we would prefer that to be the source of truth for for our optimisation flags, rather than cmake adding in it’s own defaults depending on what CMAKE_BUILD_TYPE is set to.
And yes, the upstream projects themselves may have logic on CMAKE_BUILD_TYPE as well, but many don’t, but we could patch this logic out.
That is why I was looking to see what the arch project does, and a colleague also linked the gentoo project and their cmake wrapper.
So until now we’ve just been setting CMAKE_BUILD_TYPE to None and this has for the most part worked, but I am open to better guidance on how to handle this requirement.
The clearest approach to what you are trying to achieve would probably be to define your own custom config. Give it a name that makes clear what the custom config represents, don’t use None. If you don’t define the config-specific variables CMAKE_CXX_FLAGS_<CONFIG>, they default to empty, and that sounds like what you’re wanting. This will be essentially the same as using None like you are now, but without the confusion and potential corner cases where None might be taken to mean something special (I don’t recall where I’ve seen that, better just to avoid the problem by using a better name).
One down side of using a custom config though is when you install your project, you’re installing that config, not Debug or Release. If consumers are making assumptions about what configurations a target is provided in, they may have trouble dealing with your custom configuration.
An alternative would be to overwrite flag variables like CMAKE_CXX_FLAGS_RELEASE, discarding the default contents and setting them to whatever flags want to enforce. But some projects then modify that value, which projects shouldn’t do, but it is unfortunately still common. Even then, projects can also add flags in other (legitimate) ways, so you may have a hard time truly enforcing a consistent set of flags across all projects.
Craig, thanks so much for responding with ideas on different approaches.
One down side of using a custom config though is when you install your project, you’re installing that config
This seems related to my observation: Building with CMAKE_BUILD_TYPE=None and installing with --config Release resulted in no MyLibraryTargets-<config>.cmake file being generated.
If consumers are making assumptions about what configurations a target is provided in, they may have trouble dealing with your custom configuration
I assume you mean the assumptions the library authors themselves make within their custom CMake. We can limit this somewhat by controlling the build/install types/configs on both sides, but yes its another potential source of errors.