> You suggested a settings_user.yml but the docs say that it's only for NEW data. I need to modify the list of build_types in settings.yml to extend it to have all of our custom build types. Could that be done with a settings_user.yml?
It is valid both for adding new settings (first level), adding new sub-settings to existing settings, and adding new values to existing settings values. In your case defining build_type: [MYNEW1, MYNEW2, ...] should add those configurations to the existing ones.
Is using the settings file the right way to add custom build_types or is there some place to do it that's recipe specific?
The settings_user.yml or the settings.yml are the correct place to define custom settings, including build_type. Here you can find a discussion of settings vs options vs conf: https://docs.conan.io/2/reference/binary_model/extending.html#settings-vs-options-vs-conf. In this case, I'd say that your custom build-types are in general project-wide. If they are not and they are very specific per-package, and different packages have a different built-type, you might want to use an option in those packages. It depends on your use case.
Am I correct in my usage of "-s "&:build_type=DEV_NOOPT" -s build_type=Release" (repeated for each of our custom build flavors as we discussed) to force every build type into using "Release" build products? It seems like a strange syntax and I don't see it documented anywhere. I discovered it on some stack overflow page.
Yes, this is correct. You are right we don't have this as an explicit example in the docs, and I think it might be worth it to add it. I'll create a ticket in the docs or move this to the docs repo to try to improve that.
The syntax, it is true that it is not very intuitive at first sight, but it is also true that it allows to cover some cases that we have found in our users that cannot be modeled by CMake alone. For example, there are users that can have conditional requires to the self.settings.build_type and those can be even to depend on different versions of the same library. So the "build_type" of the dependency is not the only information to be used, for example if it is a header-only library, it will not have a build_type at all. But still your &:build_type=DEV_NOOPT could depend on myheader/1.0 and your &:build_type=DEV_OPT could depend on myheader/1.2 if you need to model that dependency that way. It might not be ideal, but there are users with these needs, so we try to not to be opinionated and support those cases too.
It is valid both for adding new settings (first level), adding new sub-settings to existing settings, and adding new values to existing settings values. In your case defining
build_type: [MYNEW1, MYNEW2, ...]should add those configurations to the existing ones.The
settings_user.ymlor thesettings.ymlare the correct place to define custom settings, includingbuild_type. Here you can find a discussion of settings vs options vs conf: https://docs.conan.io/2/reference/binary_model/extending.html#settings-vs-options-vs-conf. In this case, I'd say that your custom build-types are in general project-wide. If they are not and they are very specific per-package, and different packages have a different built-type, you might want to use anoptionin those packages. It depends on your use case.Yes, this is correct. You are right we don't have this as an explicit example in the docs, and I think it might be worth it to add it. I'll create a ticket in the docs or move this to the docs repo to try to improve that.
The syntax, it is true that it is not very intuitive at first sight, but it is also true that it allows to cover some cases that we have found in our users that cannot be modeled by CMake alone. For example, there are users that can have conditional requires to the
self.settings.build_typeand those can be even to depend on different versions of the same library. So the "build_type" of the dependency is not the only information to be used, for example if it is a header-only library, it will not have abuild_typeat all. But still your&:build_type=DEV_NOOPTcould depend onmyheader/1.0and your&:build_type=DEV_OPTcould depend onmyheader/1.2if you need to model that dependency that way. It might not be ideal, but there are users with these needs, so we try to not to be opinionated and support those cases too.Originally posted by @memsharded in https://github.com/conan-io/conan/issues/16739#issuecomment-2254615571
Close https://github.com/conan-io/conan/issues/4221