Is "host" the build or the target system?

[David Holmes]

On 28/05/2012 11:59 PM, Magnus Ihse Bursie wrote:
> On 2012-05-25 20:00, Fredrik Öhrström wrote:
>> -----kelly.ohair at oracle.com  skrev:
>>> I myself am ok with just cringing everytime I use the --host options,
>>> but I still consider it an autoconf BUG,
>>> always will.
>> It did make me cringe, but only for a while, I am used to it now. :-)
>
> You might be, but you have worked extensively on the build system for a
> long time now. I think it is important that we build a system that is
> clear and accessible to all developers, with minimal need for
> documentation and education.
>
> Anyway, since obviously we're not all agreeing on how to solve this,
> let's try to break down the problem further instead of just pushing "my
> solution" against "Fredrik's solution". I think what the problem
> basically boils down to is two questions: how to control configure, and
> how to design our internal Makefiles.
>
> *1. How to control configure*
>
> Autoconf has the tradition of specifying the target platform using
> "--host". In both Fredrik's and my solution will this still be a way to
> use configure. The question is instead if:
>
> *a) *we should *only* allow this as the way to setup cross-compilation
>
> *b) *we should extend the configure script to also allow "--target", in
> a non-autoconf-standard way, to specify the target platform, and
> document this as the default way to do cross-compilation configurations.
>
> *c) *we should extend the configure script to also allow a new, third
> option, like --with-target-system, --jdk-target, --target-platform or
> something similar, and document this as the default way to do
> cross-compilation configurations. (Suggested privately to me by Kelly.)

(b) or (c) seem fine. What we are cross-compiling for is the TARGET.

> *2. How to design our internal Makefiles*
>
> The other question, that has been somewhat dwarfed in the discussion, is
> how the decision above affect our internal Makefile architecture. We
> have basically two choices:
>
> *a) *Our internal Makefile variables and functions specifying the target
> platform should be named HOST_...
>
> *b) *Our internal Makefile variables and functions specifying the target
> platform should be named TARGET_...
>
> The only reason for going with 2a) is to be consistent with the autoconf
> UI, so this solution only makes sense if you also go by solution 1a).

Right, so naturally (b) here.

> However, and this is important to point out, it is a valid and
> meaningful combination to go with solution 1a) (i.e. to only allow
> --host) and still choose 2b (i.e. name our internal variables TARGET_...).
>
>  From my perspective, the most important question is 2). The way you
> start a cross-compilation only affects a few people, and even if this is
> counter-intuitive and would require a documentation/education effort,
> once you've learnt how to do it, it's not that hard to remember.
>
> On the other hand, our internal Makefiles have TARGET_.../HOST_...
> variables all over the place. Every time you do something that is
> platform-specific, you will need to use them, regardless if you're
> cross-compiling or not. Educating *all* JDK developers who will develop
> platform specific code is a task on a completely different scale.

Target is already used extensively (though not exhaustively) to refer to 
the build output. For example, hotspot uses TARGET_OS_FAMILY_* in the 
source code.

The existing cross-compilation support also uses HOST to refer to the 
build host eg HOST_CC, HOST_JAVA_CMD.

I don't know what build-infra has already done to that existing 
cross-compilation support.

David
-----

> As for question 1), I believe any of options b or c is good, and that
> option a is unneccessary restrictive and leads to an educational burden
> that should not really be needed. However, my opinion on this is not as
> strong as on question 2. (At least not as long as Fredrik answers all
> support questions on the build-dev list on how to chose the target when
> cross-compiling ;-))
>
> /Magnus
>