[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-build-infra-dev
Subject:    Is "host" the build or the target system?
From:       kelly.ohair () oracle ! com (Kelly O'Hair)
Date:       2012-05-29 20:38:50
Message-ID: 01172EAF-833A-4782-A705-E1A75D65F73D () oracle ! com
[Download RAW message or body]


On May 28, 2012, at 6:59 AM, 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.)

I think I prefer c), make the option spelling explicitly for the jdk builds, and what \
we (the jdk team) need, and defined the way we want. As autoconf upgrades, this is \
probably the least amount of work for us.

And it is probably a good policy and important to not change the behavior of the \
existing configure options, if at all possible. Anyone mixing autoconf traditional \
host/target settings with --jdk-target gets what they get, we don't prevent it, and \
we let the user figure out what it means.

Just my 2 cents worth.

> 
> 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). 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.  
> 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 ;-))


I see no value in changing the jdk Makefiles, so I probably favor 2),  but maybe with \
a plan of changing the names to JDK_HOST and JDK_TARGET eventually (or kind of match \
the --jdk-target spelling option), so we are less likely to confuse autoconf 'host' \
and 'target' definitions.

---

The jdk build is not a cross compiler build, and the HOST and TARGET terminology, as \
it exists today in the JDK makefiles, to me refers more to the JDK being used to \
build (BOOTDIR) or the JDK being built. So I would like to see us avoid mixing these \
things up if at all possible, i.e. stray away from the autoconf options and \
terminology that direct itself specifically at building cross compilers. Create our \
own options that do what we want to do for jdk builds.

-kto

> 
> /Magnus
> 


[prev in list] [next in list] [prev in thread] [next in thread]