I am currently working on a spike solution for our company infrastructure using Conan. What i did not get so far is how distribution-specifics are handled. E.g. Qt5 has dependencies to libs like gstreamer and there are even modules like QWebengine that depend on Kernel features (v4l) not available in older Distributions like RHEL 6 so i doubt the binaries built on e.g. Ubuntu would work as expected.
Is this something that needs to be handled with a package-specific setting reflecting the distribution or is there a better way for avoiding wrong/incompatible binaries being shared between developers?
Thanks a lot for the great work and for answering this in advance.
Yes, you are very right. The default settings for conan.io is a tradeoff between being overly detailed and the opposite. We didn't include details for differentiating distros, as for the majority of cases, especially in OSS, it is not necessary.
In the enterprise environment, it is different, and specifically the differentiation and binary incompatibility problems between RH6 and 7 (or between different versions of glibc, if you prefer) are an issue, and it is totally necessary to support both. Fortunately it is easy to customize, and there are a few users that are doing something like:
settings.yml
, at the root level, something like:os: [Windows, Linux, Macos, Android, iOS, FreeBSD, SunOS]
distro: [RH6, RH7]
You can add more distros, or even have None
as a distro value.
os:
Windows:
Linux:
distro: [RH6, RH7]
Macos:
codename: [Mavericks, Yosemite]
The only thing you have to manage is that your team shares the same settings.yml. Does this answer your question? Cheers!
Yes, thanks a lot, reassuring to know that this is the way to go.
Yes, you are very right. The default settings for conan.io is a tradeoff between being overly detailed and the opposite. We didn't include details for differentiating distros, as for the majority of cases, especially in OSS, it is not necessary.
In the enterprise environment, it is different, and specifically the differentiation and binary incompatibility problems between RH6 and 7 (or between different versions of glibc, if you prefer) are an issue, and it is totally necessary to support both. Fortunately it is easy to customize, and there are a few users that are doing something like:
- If using mainly linux platforms, you can add a setting in your default
settings.yml
, at the root level, something like:os: [Windows, Linux, Macos, Android, iOS, FreeBSD, SunOS] distro: [RH6, RH7]
You can add more distros, or even have
None
as a distro value.
- If you have a more complex hierachy of OS and want to model them more accurately, you could do:
os: Windows: Linux: distro: [RH6, RH7] Macos: codename: [Mavericks, Yosemite]
The only thing you have to manage is that your team shares the same settings.yml. Does this answer your question? Cheers!
@memsharded Is this profile a valid one based on your second settings.yml?
[settings]
os=Linux
os.distro = RH6
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=4
compiler.libcxx=libstdc++
build_type=Release
[options]
[build_requires]
[env]
Or should I add a line as follows?
os_build.distro = RH6