conan-io / conan

Conan - The open-source C and C++ package manager
https://conan.io
MIT License
8.13k stars 968 forks source link

[bug] Incorrect usage of "build" profiles instead of target. #12660

Open hpe-ykoehler opened 1 year ago

hpe-ykoehler commented 1 year ago

https://wiki.osdev.org/GCC_Cross-Compiler

In Conan, the definition of host & build seems to be different than what the cross-compiling terms are in other tools.

In GCC/autotools, etc. The host is the platform you initiate the command from, the target is the machine the binaries you are building will be run on, while the build is a specific Canadian Cross-Compile terminology for when you create a tool-chain on the host that is targetting to be run on the build, as to produce a binary that runs on a target.

As such, the host/build profile notion in Conan would be better expressed as host/target instead, so as to not cause confusion with the same terms in other cross-compiling aspects.

memsharded commented 1 year ago

Hi @hpe-ykoehler

This is not a bug. Some time ago, the community pushed for following the GNU naming (https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html), in which:

There are three system names that the build knows about: the machine you are building on (build), the machine 
that you are building for (host), and the machine that GCC will produce code for (target). 
When you configure GCC, you specify these with --build=, --host=, and --target=.

The link you are providing is not from gnu.org.

It is not that I loved this naming either, but the community decided to go this way, and we will keep it, it would be simply too breaking and confusing for the value, and there will still be many users that don't thing the other approach is correct either.

hpe-ykoehler commented 1 year ago

From the document, it still shows that Conan got it wrong:

"If build, host, and target are all the same, this is called a native." "If build and host are the same but target is different, this is called a cross." "If build, host, and target are all different this is called a canadian" "If host and target are the same, but build is different, you are using a cross-compiler to build a native for a different system. Some people call this a host-x-host, crossed native, or cross-built native." "If build and target are the same, but host is different, you are using a cross compiler to build a cross compiler that produces code for the machine you’re building on. This is rare"

The "common" usage of cross-compiling is

"If build and host are the same but the target is different, this is called a cross."

As such, in the most common cross-compilation usage the build & host have the same value and the target is different.

But conan uses the "host" profile as the target, the only case where the "host" should differ from "build" are for the rarest from of cross-compilations: canadian and host-x-host

As such, I think Conan should be corrected so that when we do x86_64 to arm compilation the correct syntax be:

conan install . -pr:target=arm -pr:host=default -pr:build=default (pick either host or build I am fine)

but not:

conan install . -pr:host=arm -pr:build=default

as it is today.

memsharded commented 1 year ago

Cross-building supported in Conan is the cross-native one:

If host and target are the same, but build is different, you are using a cross-compiler to build a native for a different system. Some people call this a host-x-host, crossed native, or cross-built native.

This is the case implemented with:

conan install . -pr:host=arm -pr:build=default

You also need to take into account that Conan packages are >95% libraries, so they follow the paragraph:

In the case of target libraries, the machine you’re building for is the machine you specified with --target. So, build is the machine you’re building on (no change there), host is the machine you’re building for (the target libraries are built for the target, so host is the target you specified), and target doesn’t apply (because you’re not building a compiler, you’re building libraries). The configure/make process will adjust these variables as needed. It also sets $with_cross_host to the original --host

You can also see in other tools, like Meson: https://mesonbuild.com/Cross-compilation.html

The tl/dr summary is the following: if you are doing regular cross compilation, you only care about build_machine and host_machine. Just ignore target_machine altogether and you will be correct 99% of the time. Only compilers and similar tools care about the target machine. In fact, for so-called "multi-target" tools the target machine need not be fixed at build-time like the others but chosen at runtime, so target_machine still doesn't matter. If your needs are more complex or you are interested in the actual details, do read on.

In any case, a change like this one would be massively disrupting for little value, so it is definitely not worth at this moment.