[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Allowing both cross building and using an alternative compiler



Guillem Jover <guillem <at> debian.org> writes:

> On Mon, 2015-05-11 at 01:34:08 +0200, Matthias Klose wrote:
> > On 05/10/2015 03:32 AM, Guillem Jover wrote:
> > > CC_FOR_BUILD = gcc

Plus, what Wookey said.

> > the above mentioned wiki pages still talk about HOSTCC and BUILDCC. Please
> > clarify when to use these.
> 
> I think HOSTCC and BUILDCC should never be used, because they are either
> very confused in their meaning alternating depending on the upstream, or

Allow me to explain:

There are two coëxisting sets of nomenclature for cross-compiling around.
Both are “correct” and have their merits, but they come from different
cultures and have different goals.

Embedded systems people usually speak of “host” and “target”. In this
case, “host” is the system on which you build the image, and “target”
is the system on which you run the image. This stems from the “target”s
being not enough of a computer to be able to do things by themselves.

GNU people usually speak of “build” and “host” and, in some cases, “target”.
Here, “build” is the system on which the compilation happens, “host” is
the system on which the compilates run, and “target” is the system the
*output* of running the *compilates* is supposed to run on (only valid for
things like compilers). This is also where the “canadian cross” comes from.

So, to convert.

From ES to GNU:

host → build
target → host(, target)

From GNU to ES:

build → host
host → target
target (if == host) → target
target (if != host) → not mappable

Unfortunately, variables like HOSTCC, TARGET_CC, CC_FOR_BUILD, BUILD_CC,
etc. cannot simply be put into either scheme because of the ambiguity.
It is not right to simply say “scheme X should never be used” because
both are correct, even at the same time, they are just different sets
of naming conventions (think lpszHungarianNotation vs. dromedarCaseThing).
Instead, Debian should neutrally define a set of knobs to set, which the
debian/rules files then can convert to whatever upstream requires, which
may require nomenclature conversations. (This also means exporting those
variables must not be done by default.)

bye,
//mirabilos (hat: FreeWRT and OpenADK developer)

Reply to: