This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: update libgcj configury, try 2
- From: Tom Tromey <tromey at redhat dot com>
- To: gnustuff at thisiscool dot com
- Cc: Thomas Fitzsimmons <fitzsim at redhat dot com>, java-patches at gcc dot gnu dot org
- Date: 15 Dec 2003 15:02:09 -0700
- Subject: Re: Patch: update libgcj configury, try 2
- References: <VTA8A6WVX856SRKETQYUUS62EAVRJD.3fdbea19@p733>
- Reply-to: tromey at redhat dot com
>>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:
Mohan> I'm still scratching my head about the 10M Makefile.in
This must be some kind of record.
Mohan> I'm not that well-versed in the autotools. The verbosity in
Mohan> Makefile.in is stemming from repetition of rules like these for
Mohan> every sourcefile:
Mohan> [ cryptic stuff ]
Mohan> I didn't spend a lot of time on this, but couldn't immediately see who
Mohan> was responsible for generating the above. Is it automake itself?
Yes, automake generates this. Automake will generate an explicit rule
if you use per-target flags. This might also happen with plain
subdir-objects, I forget. We could easily test though, by removing
the various _GCJFLAGS definitions and replacing them with a single
global "AM_GCJFLAGS" (except lib_gnu_java_awt_peer_gtk_la_GCJFLAGS,
which needs -fjni).
I wonder if we'll need some kind of automake patch to handle this.
The thing is, automake does this in the name of portability across
make implementations. But we no longer care about that (if we ever
did) -- we're free to assume GNU make.
Tom