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: Andrew Haley <aph at redhat dot com>
- Cc: Nathanael Nerode <neroden at fastmail dot fm>, Ranjit Mathew <rmathew at gmail dot com>, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Tue, 20 Jun 2006 12:23:19 +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
>
>
> This would simplify the gunk at the toplevel quite a bit. Can anyone
> think of a reason not to do this?
Before I continue working on this for 4.3, I would like to have a signal
from the java maintainers, if they actually agree with this approach in
the light of:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00795.html
in which there seems to be a reluctance to make building the runtime
dependant on building the front-end.
Cheers,
David