Cleaning up JDK detection in IcedTea

[Andrew John Hughes]

After running into some interesting issues with the use of javac,
java, et al. in IcedTea recently, I've started to do some cleanup work
in IcedTea7 to make the detection of the build JDK more
straightforward and hopefully more logical.  Once stabilised, I'll
look at porting the work over to IcedTea6 as well and posting each
patch for review.

The first commit in this vein went into IcedTea7 at the end of last week:

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-July/006553.html

This patch:

* merges all the --with-gcj-jdk, --with-icedtea-home,
--with-openjdk-home options into one option: --with-jdk-home is now
the one and only option for specifying the JDK to use.
* makes more use of the JDK setting in deciding which javac, java,
jar, rmic and javah to use.
* removes --with-icedtea and --with-openjdk, replacing them with the
more accurate --disable-bootstrap

Before this change (and still in IcedTea6), --with-icedtea or
--with-openjdk (largely equivalent options, currently unified into
just --with-openjdk in IcedTea6) had the side effect of assuming that
only one build would be performed, as well as choosing to use OpenJDK
to build.  In fact, from the code standpoint, it is the use of OpenJDK
that is incidental; it has always been possible to override the actual
JDK used by using the --with-icedtea-home/--with-openjdk-home options.

Confused? I know I certainly have been many times by the numerous
options we have.  This cleanup changes things so that the status quo
is now:

  * --with-jdk-home picks which JDK to use
  * --disable-bootstrap turns on the single build variant, independent
of the JDK used

At present, there are still some assumptions about using IcedTea which
are linked to the --disable-bootstrap, namely the use of a memory
limit and the detection of Xerces/Xalan.  These will be cleaned up by
subsequent patches.

Another part of this mess was that previously, the actual components
of the JDK were decided differently depending on the option used.
Using --with-openjdk or --with-icedtea meant that java, javac, rmic
and javah were all determined relative to the JDK, while the default
GCJ option did a path-based search.  The same process is now true,
regardless of which build is used: the JDK-relative paths are used by
default, and can be overridden by --with-x options.  If
$JDK_HOME/bin/x is not present, then a path-based search will be done
as a last resort.

The compiler selection is a little more complex and still needs some
work.  We check for javac first, as always, and then ecj.  Previously
the value of JAVAC was always overridden to be "$ECJ -nowarn" anyway
if ecj was found.  Now javac will be $JDK_HOME/bin/javac if present
and ecj may also be available as $ECJ.  At present, ecj is still
always used on default builds via javac.in, but this will shortly be
cleaned up too.

The overall aim of this is hopefully to make things simpler for
everyone and reduce the differences between individual builds.  I ran
into issues with the current setup because checks done during
configure using $JAVAC give different results to what actually happens
at runtime.  In the long run, I hope these changes will make it
possible to do a quick build with gcj.  This still needs some work
breaking up the ecj patch and identifying relevant bugs rather than
applying them all.  One particular issue to look at is running Sun's
javac rather than ecj with gcj, as this is necessary to build the
java.dyn classes in OpenJDK7.

I'd welcome any thoughts you have on this, and also news of any
oddities you think could also be eradicated during this process.

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8