I'm a bit confused about cross-building with conan.
Let's say we have two profiles:
Profile_1
DEVTOOLSET="/path_to_my_toolchain/"
[settings]
os=Linux
os_build=Linux
arch=arm
arch_build=x86_64
compiler=gcc
compiler.version=7
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]
CXX="\${DEVTOOLSET}g++"
CC="\${DEVTOOLSET}gcc"
LD="\${DEVTOOLSET}ld"
AR="\${DEVTOOLSET}ar"
AS="\${DEVTOOLSET}as"
STRIP="\${DEVTOOLSET}strip"
OBJCOPY="\${DEVTOOLSET}objcopy"
RANLIB="\${DEVTOOLSET}ranlib"
CXXFLAGS="-magic-cpp-flags"
LDFLAGS="-magic-ld-flags"
Profile_2
DEVTOOLSET="/path_to_my_incompatible_toolchain/"
[settings]
os=Linux
os_build=Linux
arch=arm
arch_build=x86_64
compiler=gcc
compiler.version=7
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]
CXX="\${DEVTOOLSET}g++"
CC="\${DEVTOOLSET}gcc"
LD="\${DEVTOOLSET}ld"
AR="\${DEVTOOLSET}ar"
AS="\${DEVTOOLSET}as"
STRIP="\${DEVTOOLSET}strip"
OBJCOPY="\${DEVTOOLSET}objcopy"
RANLIB="\${DEVTOOLSET}ranlib"
CXXFLAGS="-incompatible-magic-cpp-flags"
LDFLAGS="-incompatible-magic-ld-flags"
According to docs only [settings], [options] and [build_requires] are used in package id calculation.
Thus a package will have the same id for Profile_1 and Profile_2. And it will also be considered compatible with another package that was built with either Profile_1 or Profile_2, despite being actually incompatible, because of the different toolchains.
So, the question: is there a proper canonical conan way to differentiate these profiles? Or is it that the only solution is to add a dummy [setting] for toolchain identification (e.g. my_toolchain_id="toolchain_1").
Hi @TheQwertiest,
Yes, this is something you will have to take into account if you are using the same settings in both profiles. I'd say one way to differentiate packages would be to introduce the toolchain as a subsetting of the compiler so that information is taken into account for the package ID.
I know there are other people using this approach so maybe they can help you: @theodelrieu @sztomi
@danimtb , thanks for the answer! Since there's no additional info or discussions, I'll close the issue for now, so as to not to clutter the Issue list.
PS: If anyone has any additional info and\or suggestions though, please, feel free to post here =)
@TheQwertiest yeah, I can only echo what @danimtb said. Anything that affects ABI compatibility, you will need to model in the settings. You can model _more_ (such as C++ standard level, which is not strictly ABI-breaking), but not less. I would not add a blanket "toolchain" setting though. Rather, something that explicitly describes the difference. From your example it looks like you have some incompatible flags. Then call those out in the settings. Also, you can leave out the setting from a recipe if it does not affect it.
Most helpful comment
@TheQwertiest yeah, I can only echo what @danimtb said. Anything that affects ABI compatibility, you will need to model in the settings. You can model _more_ (such as C++ standard level, which is not strictly ABI-breaking), but not less. I would not add a blanket "toolchain" setting though. Rather, something that explicitly describes the difference. From your example it looks like you have some incompatible flags. Then call those out in the settings. Also, you can leave out the setting from a recipe if it does not affect it.