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 https://github.com/conan-io/conan/issues/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?

[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 https://github.com/conan-io/conan/pull/16028/commits/2a870159489b287b1b4bb8b1f1183642ed01d2d6)

[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 https://github.com/conan-io/conan/commit/2a870159489b287b1b4bb8b1f1183642ed01d2d6)

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

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