#5958 New tool: cppstd minimum version required

[uilianries]

Add a new tool: cppstd_minimum_version:

• Receive a ConanFile instance and handle its settings to detect the current cppstd, from profile or from arguments.
• If it is not able to detect by settings, then it will extract from current compiler (from profile) and compare if such compiler version is able to manipulate the required cppstd.
• Any failure will result in an InvalidConfiguration error.
• Why not only returning False and the user take care about the exception?
  Because the error can be caused by compiler or settings, so we would need to return 2 elements (result + message) and the user will (probably) forward the message as an InvalidConfiguration.

NOTE: This feature should be affected by #5440

Changelog: Feature: New tools.check_min_cppstd and tools.valid_min_cppstd to check if the cppstd version is valid for a specific package.
Docs: conan-io/docs#1467

closes #5958
closes #4943
closes #5440

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[lasote]

@jgsogo please take care of this PR following the latest agreement in the issue. Thanks

[uilianries]

I need to update this PR, Memsharded commented sometime ago about other cppstd forms: gnu++20 and c++2x. This PR is NOT prepared to deal with exotics extensions.

UPDATE:

Conan uses alias for gnu extensions, we don't need extra settings.

[lasote]

Have you checked my last comment here? #4943

[uilianries]

Yes, the implementation for valid_min_cppstd is here

[jgsogo]

I'm asking a few changes to match the interface requested in the issue.

Also, I would like to suggest a different approach to testing: I really appreciate all these exhaustive testing, but I'd write them like unittests of the functions valid_min_cppstd and check_min_cppstd (mocking cppstd_from_settings and cppstd_flag), otherwise we are checking many other things that haven't been touched in this PR, that are already tested and we are just consuming time.

After the exhaustive ones, we should write one/two tests using an actual ConanFile loaded from disk with the TestClient to check that the full workflow is not broken in the future.

Thanks!

[jgsogo]

this one should close (if merged) #4943 too.

[memsharded]

Still, the C++ standard is the host one, not the build one. This is why the OSInfo() cannot be used!

[memsharded]

This PR is working so far with wrong hypothesis regarding the settings model and the ABI compatibility.
Maybe that model can be reconsidered, I have created an issue for it: #6157

In the meantime, this should be either adapted to the current model, or put on hold until the underlying problem is addressed.

[jgsogo]

Wow! Good catch, @memsharded!

Here we have another use case where we need the settings even though the recipe has removed all of them. It looks like that the approach for header-only libraries should preserve the settings but apply the header_only() trick in the package_id...

Nevertheless, regarding this PR, if the recipe uses the cppstd_minimum_version it should have at least the compiler setting to access compiler.cppstd and, probably, if it requires the compiler, we can require the os to be there. So, I would buy an error like: "in order to check the C++ standard, the recipe must contain os and compiler settings" . WDYT?

[uilianries]

Yes, without settings (compiler) will be impossible to use this feature.

[memsharded]

Nevertheless, regarding this PR, if the recipe uses the cppstd_minimum_version it should have at least the compiler setting to access compiler.cppstd and, probably, if it requires the compiler, we can require the os to be there. So, I would buy an error like: "in order to check the C++ standard, the recipe must contain os and compiler settings" . WDYT?

Yes, regarding this feature, this would be the correct solution. But the problem is larger that this.

Absent, as already merged in Conan-center-index, is wrong: https://github.com/conan-io/conan-center-index/tree/master/recipes/absent/all.

This feature will fail if applied to that recipe, and if we force that recipe to be created with compiler.cppstd=17, then, it will not be possible to use it, because most packages in conan-center will be missing, as they were not compiled with that setting. Either we build the whole repo with compiler.cppstd=17, or we need to relax the assumptions about binary compatibility of the cppstd standards for the same compiler version.

[jgsogo]

Yes, that's a different problem, and probably the C++ standard thing should benefit from some kind of "automatic compatible package" (opt-out?)... Many recipes now have the CXX_STANDARD required in CMake, and this tool will help Conan users to detect if the compiler will work with the recipe before trying to compile it (if no compiler.cppstd is provided, then the tool will check for the default one, which should be the one Conan uses to compile -- not sure if we are/can enforcing it). Anyway, I need to run an example to validate my hypothesis. I'm not sure about it. El jue., 28 nov. 2019 23:38, James <notifications@github.com> escribió:

…

Nevertheless, regarding this PR, if the recipe uses the cppstd_minimum_version it should have at least the compiler setting to access compiler.cppstd and, probably, if it requires the compiler, we can require the os to be there. So, I would buy an error like: "in order to check the C++ standard, the recipe must contain os and compiler settings" . WDYT? Yes, regarding this feature, this would be the correct solution. But the problem is larger that this. Absent, as already merged in Conan-center-index, is wrong: https://github.com/conan-io/conan-center-index/tree/master/recipes/absent/all . This feature will fail if applied to that recipe, and if we force that recipe to be created with compiler.cppstd=17, then, it will not be possible to use it, because most packages in conan-center will be *missing*, as they were not compiled with that setting. Either we build the whole repo with compiler.cppstd=17, or we need to relax the assumptions about binary compatibility of the cppstd standards for the same compiler version. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5997?email_source=notifications&email_token=AAKXL6FO5EDDNTZQHFAEDNLQWBB7RA5CNFSM4JGJFXGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFNQPHA#issuecomment-559613852>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKXL6FBFMEFDZVWFQGMPDDQWBB7RANCNFSM4JGJFXGA> .

[lasote]

What we want from this PR right now:

1. If self.settings.compiler.cppstd, the tool will use self.settings.compiler.cppstd to compare
2. It not self.settings.compiler.cppstd, the tool will use compiler to compare (reading the default from cppstd_default)
3. If not self.settings.compiler is present (not declared in settings) will raise because it cannot compare.

This WON'T solve the issue with c3i, where we need a way to alter the input configuration, but that's a different issue.

[uilianries]

Done! I've followed the comment #5997 (comment)