[feature] easy fallback at recipe create/build when cppstd is not invalid for building, but not for consuming

[jcar87]

What is your suggestion?

For some libraries, we may have the following situation:

A) The library uses C++ features that have been removed from newer standards, i.e. it can be built with c++14 but not with c++17)
B) This uses of removed functionality are used only in implementation files - and not exposed in the interface, i.e., a consumer can be in C++20, depend on said library that was built for C++14, and this is fine (compiler vendors make a lot of efforts to retain binary compatibility across C++ standards)

For (A), the recommended way in Conan 2.0 to reflect this is the following:

def validate_build(self):
     check_max_cppstd(self, "14")

This will prevent Conan from creating the binary with a cppstd higher than 17.

For (B), the fallback is in the compatibility.py plugin - Conan will try to find "compatible" binaries, that is, if we request compiler.cppstd=17, it will not find a binary for the library matching the configuration, but it will happily use the binary with compiler.cppstd=14 if it exists.

But the fallback in compatibility.py only works if the compatible binary already exists. If it doesn't, and one has --build=missing, it will fail during validate_build(), and the user has to explicitly express that they want cppstd=14. But this is not always intuitive: it would have to be -s "library/*:compiler.cppstd=14", otherwise it would affect all binaries, e.g. if there are dependencies.

It's a similar case during Conan create. Can we consider a fallback, similar to compatibility.py at consumption time, but at "creation" time?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide