![]() For an end user, how often is anyone realistically going to want to build more than one config in a non-scripted scenario? I’m sure there are valid use cases for this, but I have reservations whether the complexity and potential confusion this feature introduces is worth it. Shouldn’t that be the job of whatever is driving the build step? You can loop over the configs if driving it from a script. I’m wondering if we really should be providing this. The CMAKE_NMC_DEFAULT_CONFIGS variable is currently used to define the set of configs that should be built if no configuration is specified when providing a target. This also means there will always be a default configuration and there will always be a build.ninja file. Proposed change: Get rid of CMAKE_NMC_DEFAULT_BUILD_FILE_CONFIG and use the first config listed in CMAKE_CONFIGURATION_TYPES instead. Edit: Invoking xcodebuild directly will build the first config in CMAKE_CONFIGURATION_TYPES, but invoking cmake -build apparently always builds the Debug config regardless of the generator type (see this comment by. The Visual Studio generator always builds the Debug config by default if you invoke msbuild from the command line without specifying a configuration, but the Xcode generator’s behavior is more intuitive (to me). In my opinion, we should always have a default config if one isn’t specified and we can use the first one listed in the CMAKE_CONFIGURATION_TYPES variable for that choice. without specifying -config, you also get the Debug configuration with the Ninja Multi-Config generator, so it seems inconsistent that invoking the ninja build tool directly doesn’t work out-of-the-box.Īfter wrapping my head around the relevant variables, it seems to me that we shouldn’t need the CMAKE_NMC_DEFAULT_BUILD_FILE_CONFIG variable at all. For other multi-config generators like Xcode and Visual Studio, you get the Debug config by default if you don’t specify a configuration. I later worked out that I had to set the CMAKE_NMC_DEFAULT_BUILD_FILE_CONFIG variable if I wanted that to work. My first experience was typing ninja with no command line arguments and being met with an error that build.ninja was missing. I think we can and should address this before the 3.17 release. There seems to be too much focus on cross-config support at the expense of the much more likely scenario where cross-config support isn’t needed. After giving the new Ninja Multi-Config generator a spin and trying to wrap my head around its associated documentation, I’m concerned that things are currently more confusing than they should be and that the defaults are not consistent with the behavior of other multi-config generators.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |