Feature/language

[memsharded]

Changelog: Feature: New compiler.cstd setting for C standard
Changelog: Feature: Implemented compatibility.py default compatibility for different C standards
Changelog: Feature: Implement check_min_cstd, check_max_cstd, valid_max_cstd, valid_min_cstd, supported_cstd tools
Changelog: Feature: New languages = "C", "C++" class attribute to further automate settings management
Docs: https://github.com/conan-io/docs/pull/XXXX

Close #13777

[jcar87]

This is great!!

I wonder if we could address the usage of the stdcpp_library() helper.
Some recipes build libraries that have a pure "C" interface but encapsulate compiled C++ code. Downstream pure C consumers linking the static library will need to tell the linker that the standard C++ library needs to be linked as well:

Usually handled like this:

    def package_info(self):
        self.cpp_info.libs = ["zimg"]
        if not self.options.shared:
            libcxx = stdcpp_library(self)
            if libcxx:
                self.cpp_info.system_libs.append(libcxx)

This is not entirely robust, the downstream consumer may choose to use the static C++ library, which is valid - but Conan would add a conflicting flag.

Perhaps we can take advantage of this feature to make this logic redundant but also robust?

[RubenRBS]

We still need to decide if the profile detectino should fill a value for the cstd by default

[memsharded]

We have a problem with current approach:

• If we define compiler.cstd=11 in profile
• Use a conanfile.txt (no languages = "C", ... specification)
• The cstd is always auto-removed
• It is never passed to the toolchain (see failing test in 2a87015)

[memsharded]

We have a problem with current approach:

• If we define compiler.cstd=11 in profile
• Use a conanfile.txt (no languages = "C", ... specification)
• The cstd is always auto-removed
• it is never passed to the toolchain (see failing test in 2a87015)

Users wanting to support local dev must use a conanfile.txt, not a conanfile.py?

[memsharded]

I wonder if we could address the usage of the stdcpp_library() helper.

@jcar87 I am trying to check what would be the more idiomatic CMake way of doing this, but I can't find anything easy. Is there any property of targets that could be used for this? If that is the case, we could do it in CMakeDeps. If that is not the case, we might want to do it in CMakeToolchain, but that might have limitations like not usable for cmake-conan or not possible to use it per-target, while CMakeDeps will apply only to targets linking certain dependencies.