Is "host" the build or the target system?

[Jonathan Gibbons]

.. but we don't want to /build/ cross-compilers, do we?  We want to 
/use/ a cross-compiler to build OpenJDK for some platform that is not 
the same as the build platform.  What does the GNU autoconf manual say 
about that?  At least let's compare apples and apples.

-- Jon

On 05/24/2012 02:13 PM, Fredrik Öhrström wrote:
> Hey guys! You are falling into the old tar pit of "not invented here" mentality that Sun was rather (in)famous for.
>
> If there is a standard, then we should follow it.
>
> Let me quote from the GNU autoconf manual
> "Based on the experience of compiler writers, and after long public debates, many aspects of the cross-compilation chain have changed:" and "The relationship between build, host, and target have been cleaned up:"
>
> Thus, the people responsible for autoconf/configure have already rehashed this several times. This is what they came up with,
> and this is what is described on all pages when you search for cross compile, and this is what is described on wikipedia about
> cross compiling and autoconf, and this is what is used by other projects that use configure and autoconf.
>
> We cannot just change the default behavior of configure, just because it feels better with some other english words....
>
> You are running on i686-unknown-linux-gnu,
> you want to build a cross compiler, then use:
> --target=sparc-sun-solaris2_10 when configuring gcc
>
> Now you want to use your newly created cross compiler (sparc-sun-solaris2_10-gcc in your path)
> to build a binary of application foo, for your sparc:
> --host=sparc-sun-solaris2_10 when configuring foo
>
> To hack configure to alias --target to --host will not make life easier for us and it will introduce
> a use case that we will have to support for ever, and this might be difficult in the future when
> autoconf is upgraded.
>
> At the moment, we cannot compile static binaries from the OpenJDK, we only run within a runtime,
> but it clearly is not farfetched to assume that such a feature would be desirable. gcj has it already.
> Thus --target might be valuable for exactly its specified purpose some time in the future.
>
> Sorry for the quick backout, but I had to back out the change quickly since it affected quite a lot of variables
> and it would be inconvenient if someone managed to do another merge after it.
>
> //Fredrik
>
> ----- kelly.ohair at oracle.com skrev:
>
>> Ok.  You've sold me the bridge. I may need some time and a few glasses
>> of wine, but I think I am with you.
>>
>> I'm still a little shocked at the autoconf terminology.  Seems like
>> they completely complicated things for a situation
>> that was extremely rare and few people would ever need to do or even
>> care about.
>>
>> For the record, I'm in favor of your compromise.  Thanks for the time
>> in explaining it to this autoconf novice, me. ;^)
>>
>> -kto
>>
>> On May 24, 2012, at 1:30 PM, Magnus Ihse Bursie wrote:
>>
>>> On 2012-05-24 17:00, Kelly O'Hair wrote:
>>>> So we should talk about this, and maybe come up with a compromise
>> or alternative terminology.
>>> Just to be clear: My suggestion was to use "build system" for the
>> platform you are building on, and "target system" for the platform the
>> resulting binary should run on, and that we should stay clear of
>> "host".
>>> Rationale: "build system" and "target system" seems hard to
>> misunderstand, regardless of your previous experiences.
>>> "Host" on the other hand, is vague enough to be able to be used in
>> the sense of "build system" (as in the old openjdk makefiles) or as
>> "target system" (as in the autoconf tradition), depending (I guess) if
>> your mindset is centered on the build process or the resulting binary.
>> So I say: don't use it at all.
>>> This means that:
>>> * The openjdk tradition of calling the target system "target" is
>> kept, but the build system will be renamed from "host" to "build".
>>> * The autoconf tradition of calling the build system "build" is
>> kept, but the target system will be renamed from "host" to "target".
>>> I think it sounds like a good compromise. :)
>>>
>>> /Magnus