conan-io / cmake-conan

CMake wrapper for conan C and C++ package manager

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[develop2] Unable to build for different archtectures without changing the default profile

CedricSchmeits opened this issue · comments

The architecture is not inserted into the conan_host_profile

Also from within CMake several paths have been set to the compiler. This is not taken over in conan_host_profile, it just always adds the line include(default), it becomes impossible to build for different architectures, without the need of somehow changing the users default profile.

CMAKE_CXX_COMPILER := /usr/bin/aarch64-linux-gnu-g++
CMAKE_C_COMPILER := /usr/bin/aarch64-linux-gnu-gcc

Within the new conan v2 how should this look like. As I understood it in conan v1.5 I used a profile with the following content:

TARGET_HOST=aarch64-linux-gnu
[settings]
arch=armv8
[env]
CHOST=$TARGET_HOST
AR=$TARGET_HOST-ar
AS=$TARGET_HOST-as
RANLIB=$TARGET_HOST-ranlib
CC=$TARGET_HOST-gcc
CXX=$TARGET_HOST-g++
LD=$TARGET_HOST-ld
STRIP=$TARGET_HOST-strip

But as I understood it correctly this [env] is deprecated within conan v2. So how does one do this now? Would it be an option to add in the [settings] section an option like compiler.prefix=/usr/bin/aarch64-linux-gnu-?

commented

Hi @CedricSchmeits

Thanks for reporting this. It is true that the current implementation do not perform any architecture detection (and relies on having the "default" compiler defining it, which is just an approximation, it would be better to detect the actual arch and map it to the Conan settings).

The open PR #521 will do it for Android only, it should be extended to other architectures and platforms.

I already have some changed that cover the linux builds using gcc. Those are quite simular to the PR #521. So as soon as that's being merged I will add my changes on top of that.

But I'm wondering how the actual cross-compiler should be passed to conan 2?

commented

The compiler definition best way in Conan 2.0 is tools.build:compiler_executables, because it can be even a bit more generic than CC/CXX variables for build systems that don't listen to those variables. So the idea is that the profile detection could be setting this [conf] (in the same way #521 is setting the android ndk path).

So that means with respect to this example I would need to add something to the profile like:

[conf]
tools.build:compiler_executables={"c": "aarch64-linux-gnu-gcc", "cpp": "aarch64-linux-gnu-g++"}

or in case that it would be in a different path:

[conf]
tools.build:compiler_executables={"c": "/path/to/bin/aarch64-linux-gnu-gcc", "cpp": "/path/to/bin/aarch64-linux-gnu-g++"}
commented

Yes, exactly. I think that setting it based on the value of CMAKE_XXX_COMPILER makes sense, if it contains a path, with the path, if it doesn't contain a path, it would be assumed to be in the path already, so other packages build will find it with just the compiler name. So Conan shouldn't be trying to guess too much, just getting the current info it gets from CMake and pass it to Conan conf.

With #510 you could also set that in CMake.. @memsharded sorry for spamming this under every issue it applies to but I think it is important to highlight the use-cases of it..