[question] Compatibility of packages with `cppstd=None`

[fschoenm]

What is your question?

Hi, for historical reasons we have a lot of packages that haven't set a compiler.cppstd. Instead we used shared CMake scripts to define the C++ standard or just used the default. So far we didn't run into problems but recently we encountered a few Conan Center packages that require a C++ standard to be set.

We'd like to slowly introduce correctly setting compiler.cppstd but we would still like to keep using a few old packages before rebuilding everything.

I noticed that the default cppstd_compat.py extension ignores packages with compiler.cppstd set to None. Do you have a recommendation how we best tackle that situation?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[AbrilRBS]

Hi @fschoenm thanks for taking the time to submit this question.

While at first glance mixing and matching the cppstd values for libraries might lead to issues, in your case it seems like you control which values have been used to actually compile them, so even if it's still a bit risky, Conan can do this if you modify the compatibility plugin a bit:

The idea would be to have the compatibility plugin check for dependency packages without the compiler.cppstd setting when you're building one package that already has it defined.

While this feature would be a bit experimental, as coverage for it is minimal, the main changes would be:

• In your extensions/plugins/compatibility/compatibility.py file, after the line that currently reads # Append more factors for your custom compatibility rules here, add a call to a function of the form:

def no_cppstd_compat(conanfile):
  # Do we have the setting?
  cppstd_version = conanfile.settings.get_safe("compiler.cppstd")
  if cppstd_version is None:
      return []
  return [{"compiler.cppstd": None}]

• This will add an alternative to the packages Conan looks for, which has the compiler.cppstd subsetting unset, which will let you find your packages created without the setting

Last but not least, remove the initial

# This file was generated by Conan. Remove this comment if you edit this file or Conan
# will destroy your changes.

lines in your compatibility.py file so that Conan does not overwrite it in the next version migration.

You can see an example of this suggested approach in #19031, which aims to document and test this approach. Let me know if this helps and if it works for you, happy to answer more about the idea if needed :)

[fschoenm]

@AbrilRBS Thanks for the detailed answer.

While at first glance mixing and matching the cppstd values for libraries might lead to issues, in your case it seems like you control which values have been used to actually compile them

Is that really the case? I found a post from a GCC developer (https://stackoverflow.com/a/49119902), which states that the -std setting should not have impact on the ABI compatiblity:

For GCC it is safe to link together any combination of objects A, B, and C. If they are all built with the same version then they are ABI compatible, the standard version (i.e. the -std option) doesn't make any difference.

Why? Because that's an important property of our implementation which we work hard to ensure.

Where you have problems is if you link together objects compiled with different versions of GCC and you have used unstable features from a new C++ standard before GCC's support for that standard is complete.

---

You can see an example of this suggested approach in #19031, which aims to document and test this approach. Let me know if this helps and if it works for you, happy to answer more about the idea if needed :)

Changing the compatibility plugin makes sense. I just saw that there are more tickets linked to your PR. Are you planning to support this feature natively somehow or does it only affect documentation?

[AbrilRBS]

which states that the -std setting should not have impact on the ABI compatiblity

While for some specific circumstances that's the case, the general case is not as rosy. We recently gave a talk on just this topic https://cppcon2025.sched.com/event/27bOC/could-we-handle-an-abi-break-today and although the video is not out yet, I'll let @jcar87 himself chime in for more details :)

Are you planning to support this feature natively somehow or does it only affect documentation?

The feature for the compatibility plugin is already supported, the linked PRs are:

• Tests for its functionality, as removing the setting in the compatibility is not yet covered
  • This will come with a docs PR to also document this behaviour
• A new feature to be able to unset settings from the CLI, but it's not related to your use-case

[fschoenm]

@AbrilRBS I see. Thank you for the example implementation. I'm going to try it that way then :)