Is "host" the build or the target system?

[Kelly O'Hair]

I've been in and out of the compiler business for 30+ years, I was never exposed to autoconf.
I worked on simulators and cross compilation projects for many years. Starting in 1979.
We ALWAYS called the "host" the system you were building on, and the "target" what you were targeting.
This had nothing to do with the jdk back then or any open source efforts.
I don't have any references to my old compiler books to back this up, but I find it HIGHLY confusing what autoconf
has done here with it's terminology.

When I agreed we should try and use autoconf for the build-infra, it was with the understanding that we would
need to bend it to our will, and make it work for us on Solaris and Windows, given the unusual situation of
the jdk builds. The jdk is NOT your normal open source project, we cannot use the standard defaults here.
I don't think adopting what I consider broken terminology the right way to go here.
Yes, we do need to adopt autoconf but we also need to adapt autoconf to our needs.

Your point about the build-infra repos not needing a formal review is right, this is a sandbox for
us to experiment, I see no need for it, we can make whatever changes we want, it's when it gets formally
integrated through the jdk8/build forest that we need the open review.

So we should talk about this, and maybe come up with a compromise or alternative terminology.

-kto

On May 24, 2012, at 7:20 AM, Fredrik Öhrström wrote:

> In 1994 the autoconf tool added support for --build --host and
> --target with the meanings:
> build = build system
> host = system that run the binary, ie the system that hosts the binary
> target = only valid for compilers, and is the target arch of the hosted compiler
> 
> The first release of Java was in 1996, thus the configure standard is
> the oldest.
> 
> Secondly, the old openjdk makefiles are not consistent and not
> supportive of crosscompilation.
> Instead they can be more seen as allowing themselves to be nudged to
> cross compile.
> For example, not even HOST is used consistently for example: HOSTCC
> HOST_CC and NIO_CC
> have to be set. Thus there is no extremely consistent standard in the
> old makefiles to follow.
> 
> Third: more people know how to cross compile using configure than who know
> how to cross compile using the old openjdk makefiles. The configure way simply
> takes precedence.
> 
> Fourth: even though there  is no formal review process in the
> build-infra forest, there will
> be a formal review when it is pushed to the build forest. Thus pushing
> large changes to
> existing code must be verified with all stakeholders, lest the change
> might get backed out.
> 
> The email thread that discussed this significant change in the
> variable names and the configure
> api had the subject "hg: build-infra/jdk8: 2 new changesets", not an
> easy one to spot.
> 
> //Fredrik