This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure
- From: David Ayers <d dot ayers at inode dot at>
- To: Nathanael Nerode <neroden at fastmail dot fm>
- Cc: Ranjit Mathew <rmathew at gmail dot com>, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org, dannysmith at users dot sourceforge dot net, Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Date: Sun, 11 Jun 2006 13:56:45 +0200
- Subject: Re: [MinGW] PR target/19970: Java unnecessarily disabled for MinGW in top-level configure
- References: <4486D4AB.8000104@gmail.com> <e698k6$dkh$1@sea.gmane.org> <448889F0.8080803@inode.at> <448B4CB3.6000906@fastmail.fm>
Nathanael Nerode schrieb:
> David Ayers wrote:
>
>>>Yet I fail to understand the need for --enable/disable-libgcj if it is
>>>merely being used to enable/disable java. Why isn't that being done via
>>>language variable?
>
>
> Probably historical. :-)
>
> Perhaps you could work up a patch for the top level which does the
> following:
>
> (1) removes --enable/disable-libgcj
> (2) changes the list of default languages to not include Java for the
> former targets which defaulted to --disable-libgcj, and to include Java
> for the other targets. (While you're at it you could enable Java by
> default on MinGW.)
> (3) determines whether or not to build the libgcj subdir et al. based on
> the presence of Java in the language list
Sure, I can work on that. But I think this would be something that
should be done after the release branch is created (potentially
backported, if it truly turns out to make things a lot easier).
I think for the release branch it seems safer to apply:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00410.html
Then we should decide whether java should be enabled by default for
MinGW on trunk and mainline with the obvious patch first. (I'm not sure
whether to interpret your suggestion is a pre-approval for enabling Java
by default for MinGW, or whether we need a buy-in from a MinGW
maintainer [I've cc:ed Danny Smith].)
> This would simplify the gunk at the toplevel quite a bit. Can anyone
> think of a reason not to do this?
I'll take a shot this, but I think we should take the more conservative
route for the release branch for now, and apply the posted patch.
Cheers,
David