Ability to override compiler from environment

[Andrew John Hughes]

On 25/06/2008, Dmitri Trembovetski <Dmitri.Trembovetski at sun.com> wrote:
>
>
>
snip..

> > anybody ever tried it on windows. In theory with cygwin you should be
> > able to get enough of the gnu toolchain to get it working. But icedtea
> >
>
>   Theories seldom work well when applied to Windows, unfortunately,
>   as Kelly would attest. But I guess we won't know until we try.
>
>

I can guarantee that configure will fail on Windows; it tests for ALSA
and fails if it isn't found.  I think this is stopping Mac OS X and
probably will stop OpenSolaris too so probably should be made
optional.  twisti, how did you get round this for OpenSolaris?

I also think the fact that it tests for X headers and libraries would
be a fundamental flaw.  They may be present with cygwin but I doubt
that the X peers will be built on Microsoft Windows.

> > autotools support was also added to make bootstrapping through other
> > libre java implementations like gcj possible. The cygwin gcj port
> > however is, as far as I know, still a version behind the version we
> > really need (including 1.5 language support). That said, there is a
> > --with-openjdk configure flag that should in theory work as soon as you
> > have an pre-existing openjdk build already. But we would indeed need
> > testers for that platform. For some reason it isn't a very popular
> > development platform for Free Software hackers.
> >
>
>   How the Free Software hackers would ensure that their changes
>   to the shared code in the openjdk don't break Windows if they
>   never build or test there? Unfortunately that could easily
>   happen (and did in the past).
>

I had this thought when reading the OpenJDK developers guide.  I think
a continuous build system is needed for OpenJDK in the very near
future, if you want to guarantee this.  FOSS developers aren't going
to use a non-Free platform like Windows, and are unlikely to use a
partially non-Free one like OpenSolaris.

I don't see any reason IcedTea couldn't be built on other platforms as
well.  I think it's a generally useful tool while the build system
remains as is in OpenJDK:

* It remembers the 37 or so environment variables used to configure
the OpenJDK build.  I'd end up doing something similar myself if it
wasn't for IcedTea via a script.
* It tests for dependencies *apriori*.  Some of this is done by the
sanity check in OpenJDK, but I don't believe it checks as much and the
checks are nowhere near as easy to create.
* As Mark mentioned, it allows the existing Free Java environments to
be used to build.  This is essential until OpenJDK is ubiquitous,
which will take time.

For these reasons, I'd use IcedTea even if it wasn't applying patches
to fix issues or overlaying additional stuff like javaws,
gcjwebplugin, Gervill and Rhino.

On a side note, can someone tell me why IMPORT_BINARY_PLUGS is still
true by default even though the SNMP plugin is optional now (and thus
no plugs are needed).  I think the great work in making OpenJDK6
encumbrance free has largely been missed by many people -- it took me
a failed build and grep to work out that I needed this option which
doesn't seem to be documented.

>   Thanks,
>     Dmitri
>
>


-- 
Andrew :-)

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