Is "host" the build or the target system?

[Fredrik Öhrström]

It says use --host.

2012/5/24 Jonathan Gibbons <jonathan.gibbons at oracle.com>:
> .. 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
>
>