[question] requirements versions in yml?
See original GitHub issueCurrently, dependencies versions are hardcoded in conanfile.py For most recipes, it plays well whatever the library version.
But I’m trying to package Vulkan-ValidationLayers. It has 3 dependencies:
- Vulkan-Headers
- glslang
- SPIRV-Tools
Vulkan-Headers is not backward compatible. The version of Vulkan-ValidationLayers is tightly coupled with Vulkan-Headers one. glslang and SPIRV-Tools seem to be backward compatible (not sure, but I was able to build “old” versions of Vulkan-ValidationLayers with recent versions of glslang and SPIRV-Tools).
Even if Vulkan-ValidationLayers and Vulkan-Headers follow more or less the same versionning, there is not always a perfect match.
Here is an example of what I could use in conandata.yml:
requirements:
"1.2.135.0":
- name: "glslang"
version: "8.13.3559" # not compatible, missing members in spv namespace
- name: "spirv-tools"
version: "2020.1"
- name: "vulkan-headers"
version: "1.2.135.0" # strict requirement
"1.2.131.2":
- name: "glslang"
version: "8.13.3559"
- name: "spirv-tools"
version: "2020.1"
- name: "vulkan-headers"
version: "1.2.131.1" # strict requirement, there is no 1.2.131.2 for vulkan-headers
"1.2.131.1":
- name: "glslang"
version: "8.13.3559"
- name: "spirv-tools"
version: "2020.1"
- name: "vulkan-headers"
version: "1.2.131.1" # strict requirement
"1.1.130.0":
- name: "glslang"
version: "8.13.3559"
- name: "spirv-tools"
version: "2020.1"
- name: "vulkan-headers"
version: "1.1.130.0" # strict requirement
"1.1.126.0":
- name: "glslang"
version: "8.13.3559"
- name: "spirv-tools"
version: "2020.1"
- name: "vulkan-headers"
version: "1.1.126.0" # strict requirement
"1.1.121.0":
- name: "glslang"
version: "8.13.3559"
- name: "spirv-tools"
version: "2020.1"
- name: "vulkan-headers"
version: "1.1.121.0" # strict requirement
"1.1.114.0":
- name: "glslang"
version: "8.13.3559"
- name: "spirv-tools"
version: "2020.1"
- name: "vulkan-headers"
version: "1.1.114.0" # strict requirement
In this example glslang and spirv-tools could be hard coded in conanfile I guess, but not vulkan-headers.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:9 (9 by maintainers)
Top GitHub Comments
This is interesting, but it can get complicated. Maybe there are different version ranges for different configurations or OSs. For example, if you activate option XXX that enables some feature then you will use a different version range… and this is not tractable in a declarative way (it can become hard).
This declarative way could serve most of the cases, but not all. Still some checks will be hardcoded inside the recipe when they depend on configurations. Do we want it only for some references?
Maybe all we need is some kind of tool and write:
IMO, it is quite straightforward for recipe authors and readers, and it covers all the use cases, it can be very specific about the configurations the check applies to…
One missing use-case though, the one I talked to you about: the bot that tries to upgrade the version of requirements as soon as they are available. This scenario is a bit different, as the bot will try a version of the requirement and try to build the packages for all the configurations, if any configuration fails, that version will be forbidden to the bot (but it might work for a user using a specific configuration). I mean, the version_range won’t be the same for consumers and for the C3i-bot and probably they shouldn’t try to share the same storage.
It appears that, among all history of releases, there is only one version of Vulkan-ValidationLayers which requires a different version of Vulkan-Headers than its own version. Thereby it’s acceptable to do something like this: