conan: conan profile for gcc "compiler.version=5" does not resolve packages with "compiler.version=5.4"

Hi,

we found an issue concerning the gcc-compiler (version) and the package resolving algo. History: Our CI system created packages using the conan settings at command line like conan create . MyProduct1/1.0.0@user/channel -s compiler=gcc -s compiler.version=5.4 .... When searching for these packages the output contains compiler.version: 5.4. Because all jobs used the same command line, everything works as expected and everything was fine. I know this was probably not the best idea due to gcc 5 compatibility but on the other hand it is not completely incorrect. Now: After the discussion in another issue we switched to conan profiles as suggested by @memsharded which are distributed through a zip file and installed using the conan config install. Therefor I collected all default profiles of all our different slaves (Windows & Linux with different compiler versions) and put them into that zip file. But now packages which are formerly built with the same gcc and with the command line setting -s compiler.version=5.4 can no longer be found, (I think) because "compiler.version=5.4" != "compiler.version=5".

But IMHO these packages (with compiler.version=5.4) should also be found when a depending package is built with compiler.version=5.

Best Aalmann

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 18 (8 by maintainers)

Most upvoted comments

This could be related with the GLIBC issue, where it matters the retro-compatibility. I add this to the 2.0 milestone to see if we can improve the settings model to support this use case of “compatible” possible values of settings.

lasote on Nov 27, 2018

If you want to mix them you need to implement a package_id() method in your recipes to allow the mix:

from conans.model.version import Version
def package_id(self):
    v = Version(str(self.settings.compiler.version))
    if self.settings.compiler == "gcc" and v >= "5": 
        self.info.settings.compiler.version = v.major

lasote on Apr 23, 2018