[question] Compatibility Issues about conan HOT 5 CLOSED

Hi @Peddaahh

Thanks for your question.

The LabVIEW version (e.g. 2020) and the arch (e.g. win64) is set via options.

Why? Why not using settings instead? It would be recommended to use settings, if those need to match for all dependencies.

self.options.lv = lvf[0]
self.options.arch = arch

There is a misconception in this. The options cannot be defined from file contents. options and settings are "inputs". It is something that the user define the value, in an "imperative" way, for example in the profile and the package will follow. Trying to read the value from a file is against this and will most likely cause issues. As an example, a recipe cannot decide that it is options.shared=True based on some file contents, it is the opposite, when I say -o mypkg*:shared=True the final package must be a shared library, no matter what the files say.

-o lv="2021" -o arch="win32"

Please recall that for the general case it is necessary to use the package name or a pattern, like -o *:lv="2021" -o *:arch="win32". This would be easier if using settings instead of options.

Regarding the compatibility() thing I think it goes like this:

• You are passing lv=2021 as input
• The compatibility for v in range(int(self.options.lv), self._current_year): defines from that year to the future that is 2021, 2022, ... 2024
• The existing binary is lv=2020, as said in the output: existing: lv=2020
• So the existing binary existing: lv=2020 is clearly not in the range of compatible binaries that you defined [2021-2024]

So the range is incorrect, it needs to go backwards. If someone asks for 2021, you want the valid range [2021, 2020], not the other one+2021-2024]. So an inverse range from the current option.lv to the oldest possible one, in that inverse order, like if lv=2023, you want [2022, 2021, 2020] in this order, to prioritize more modern packages. The range defines the "fallback" order of compatibility: "if I dont have a 2023 binary, then I will try 2022, 2021, 2020 in this order"

Please try that and let us know.

from conan.

Thank you! Just for clarification before I'll try out the rest:
I did it this way, because that's how I managed dependencies in the past. There was a shell script which looked the version and arch up using this file. Then I saw I could use settings, however I did see that I can only put in predefined values for predefined settings. Then I came across the options an thought it could work that way. So I implemented it according to this: https://docs.conan.io/2/reference/conanfile/attributes.html#default-options

from conan.

I did it this way, because that's how I managed dependencies in the past. There was a shell script which looked the version and arch up using this file. Then I saw I could use settings, however I did see that I can only put in predefined values for predefined settings. Then I came across the options an thought it could work that way. So I implemented it according to this:

Settings are extensible too. You can add the settings and values that you want to your settings.yml, and you can share it via conan config install/install-pkg together with the rest of your configuration (remotes, profiles, etc). Conan 2 even has a settings_user.yml that allows easier extension and maintenance.

Check https://docs.conan.io/en/1.64/extending/custom_settings.html for more info.

Read this discussion to help deciding which is the best: https://docs.conan.io/2/reference/binary_model/extending.html#settings-vs-options-vs-conf

from conan.

Okay thanks for the help
I did adapt it to your suggestions, and also works now

from conan.

Great, thanks for the feedback!

from conan.