Create an explicit example for dependencies in one build-type and &:build_type other

[memsharded]

          > 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.

Originally posted by @memsharded in conan-io/conan#16739 (comment)

Close conan-io/conan#4221