[question] How to define ABI compatibility for Visual Studio

[forry]

What is your question?

Hello,
I'm considering migrating our repository to conan 2.0. We have lot's of packages with prebuilt binaries for Visual Studio. The recipes mostly only define one method telling that different compiler versions and toolsets are compatible so you can mix and match them. This yields a lot of combinations. The package binaries were loaded using export-pkg with the -pf argument so we don't have the binary duplication in the export folder.

1. I don't see a -pf argument in export-pkg anymore is it somehow replaced by defining a layout? How?
2. Even when I just run conan export-pkg . --user=user --channel=prebuild the conan complains: ConanException: 'self.settings' access in 'package_id()' method is forbidden. I have read about the compatibility() method but since I'm not a python programmer I don't quite understand if that applies to my case and if yes, how exactly I'm to generate the resulting super object for this case - all of the different combinations of compilers and toolsets.

Here is the example conanfile.py:

from conan import ConanFile
from conans.model.version import Version

class SomePackage(ConanFile):
    name = "somepackage"
    version = "1.0.0.38"
    license = ""
    author = "***"
    url = "***"
    no_copy_source = True
    settings = "os", "compiler", "arch"
    
    def package_id(self):
        v = Version(str(self.settings.compiler.version))
        toolset = str(self.settings.compiler.toolset)
        if self.settings.compiler == "Visual Studio" and (v >= "15" and v <= "17") and any((toolset == x for x in ["None", "", "v141", "v142", "v143"])):
            self.info.settings.compiler.version = "15 compatible"
            self.info.settings.compiler.toolset = "v141 compatible"

Thanks
Forry

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @forry

Thanks for your question.

The path forward to 2.0 might depend on what you want to achieve. Conan 2.0 has some new capabilities like a better compatibility.py external plugin that allows to customize the binary compatibility model at will. This can be useful if you want every binary to track perfectly how it was built (it will contain a unique package_id for the exact configuration, and the conan list can show the exact compiler version and toolset that were used to build that binary.
While in the current model, it is basically doing some "information erasure", wiping the compiler version and toolset and replacing it with a common placeholder for the range of valid versions.

There is nothing bad in that, if that model is working fine for you, then I'd recommend to continue doing it. I'd say that the only change you need to do to your recipe is adding the info.

Also, please note that Visual Studio compiler setting (with versions 15, 16, 17. etc) has been replaced in 2.0 by msvc (with versions 190, 191, 192, etc). So you will need to take both into account. (msvc also exist in Conan 1.X, if you want to update to it in 1.X too, not necessary, but possible).

So it could be something like this:

def package_id(self):
        v = Version(str(self.info.settings.compiler.version))
        compiler = str(self.info.compiler)
        toolset = str(self.info.settings.compiler.toolset)
        if compiler == "Visual Studio" and (v >= "15" and v <= "17") and any((toolset == x for x in ["None", "", "v141", "v142", "v143"])):
            self.info.settings.compiler.version = "15 compatible"
            self.info.settings.compiler.toolset = "v141 compatible"
       if compiler == "msvc" and (v>="191" and v <= "193"):
            self.info.settings.compiler.version = "15 compatible"  # you can use the same, whatever convention you like
            self.info.settings.compiler.toolset = "v141 compatible"

I have splitted into 2 ifs for clarity, but it could be an or condition in a single if.

Please try that and let us know.

[forry]

Thank you for your swift answer. It brings even more questions. The ones about the compatibility method and plugin I may open a new issue about it, but since there is a warning about it being a preview feature, I'm not very keen to try it out right now.

But about the msvc being the new "default". I wonder why the conan profile detect did not assign a toolset and also why there are only old toolsets in the settings.yml, ending with v141_xp (I have msvc 2022). It seems that the toolset is the real thing that dictates ABI, not the compiler version. I had the impression from conan 1 that the msvc is an obsolete record. Is now the preferred way for every developer/company to maintain their settings and profiles on their own? Also, we are using CMake to run conan with the macros from conan.cmake. I wonder how that will work out.

I'm sorry I haven't read the whole documentation yet but I wanted to start with a small recipe and work it out gradually.

[memsharded]

If you haven't please have a look at https://docs.conan.io/2/introduction.html#navigating-the-documentation

preview: When a feature is released in preview mode, this means it aims to be as final and stable as possible. Users are encouraged to use them, and the maintainers team will try not to break them unless necessary. But if necessary, they might change and break.

This is a chicken and egg problem, we don't make it stable because we are looking for users feedback first, but if we don't get users feedback, it is also very difficult to declare it stable

But about the msvc being the new "default". I wonder why the conan profile detect did not assign a toolset and also why there are only old toolsets in the settings.yml, ending with v141_xp (I have msvc 2022). It seems that the toolset is the real thing that dictates ABI, not the compiler version.

The msvc was a result of the community design from the Tribe: conan-io/tribe#5, wanting the compiler version to be the msvc one, that is the 190, 191, etc.
The toolset and the compiler version are directly correlated (not as the IDE version), so it is not an issue

Also, we are using CMake to run conan with the macros from conan.cmake. I wonder how that will work out.

We are also starting to provide a experimental cmake-conan integration, based on dependency providers in the develop2 branch of: https://github.com/conan-io/cmake-conan/tree/develop2. Feedback welcome too.

[forry]

I have been looking at the things that you suggested. I've found in the package_id a thing that I've been looking for, which was that chapter about ABI compatibility that was in one place in the conan 1 doc. It would be great if the "chapters" were the same where it makes sense so that people can look them up through the same search query as they did in conan 1. Maybe it's just me but I have always found the doc to be difficult to navigate and not very intuitive.

There seems to be an error in the code snippet or I am doing something wrong with my tests. It's the problem I had the first time. There is access to self.settings instead of the self.info.settings in the if statement.
https://docs.conan.io/2.0/reference/conanfile/methods/package_id.html#partial-information-erasure
The same is in the migration guide in conan 1.
https://docs.conan.io/1/migrating_to_2.0/recipes.html#migrate-conanfile-compatible-packages-to-the-new-compatibility-method

Also, it would be nice to run the doc through some kind of English grammar-checking tool or write it using one.

[memsharded]

Yes, it seems a bug in the docs. We will fix it to add the correct self.info.xxx syntax.

Regarding the documentation, the thing is that Conan 2.0 is a rewrite from scratch. We are not trying to do a parallelism, because we know it was a bit difficult to navigate. Now there is an important "tutorial" section, intended to be read as a hands-on, exercises and code included, and a more ordered reference. We will be completing things there, but it takes time.

I am moving this to the docs repo to fix that.

[memsharded]

This PR #3140 will fix that, and close this issue.

Is there any other question, or is it clear now with the fix to the docs? Thanks!

[memsharded]

Closed by #3140

[forry]

No, thank you very much. My mistake was to assume that the release of 2.0 meant that the doc is complete and that I'd skipped most of the tutorial parts (to save time) to go to the things that I was interested in in the reference, since I knew the conan 1, or tried to find corresponding chapters to get a refresher. I need to backtrack a little and get a feel for it, then I will probably raise a new question/suggestion about the compatibility and its documentation unless I find it open.

[memsharded]

Good, thanks very much for the feedback!
Don't hesitate then to open new tickets if you have further questions.

[forry]

Quick one. Have you fixed the second one in the migration guide (https://docs.conan.io/1/migrating_to_2.0/recipes.html#migrate-conanfile-compatible-packages-to-the-new-compatibility-method) in the "To" section there seems to still be a self.settings, after a hard refresh. I guess it would work in conan 1 but not in conan 2? Or is the self.settings ok to use in the compatibility() method, which then leaves me confused even more :)?