Tom Fitzsimmons (CCd) has been working on upgrading libgcj to use
newer auto* tools. This has gone swimmingly, except one problem with
automake.
A little background. libgcj is pretty big. It has 2,243 .java
files at the moment. Previously it has been using its own slightly
hacked automake
On 16 Dec 2003, Tom Tromey wrote:
The problem is, automake generates an explicit rule for each
compilation. Our resulting Makefile.in is nearly 9 megabytes. This
is really much too large -- compare to 200K with automake 1.4.
I have observed the same problem myself. It is not language
%% Bob Friesenhahn [EMAIL PROTECTED] writes:
bf Per-subdirectory rules and definitions can be added in order to
bf significantly reduce the amount of redundant code, and to
bf re-enable the capability to usefully override parts of the default
bf Makefile.in.
Not if you want to continue
On 16 Dec 2003, Paul D. Smith wrote:
%% Bob Friesenhahn [EMAIL PROTECTED] writes:
bf Per-subdirectory rules and definitions can be added in order to
bf significantly reduce the amount of redundant code, and to
bf re-enable the capability to usefully override parts of the default
bf
On Tue, 16 Dec 2003 09:49:44 -0700, Tom Tromey wrote:
Tom Fitzsimmons (CCd) has been working on upgrading libgcj to use
newer auto* tools. This has gone swimmingly, except one problem with
automake.
A little background. libgcj is pretty big. It has 2,243 .java
files at the moment.
Another thing that would help reduce Makefile size is to introduce
synonyms for subdirectory paths. For example,
java/awt/print/$(DEPDIR)/
could be reduced to $(am_f123). This would of course obfusticate the
Makefile, so it should be made optional, or allow the user to specify
part of the
I would like to point out that my previous gripe about the unnecessary
translation of Automake target names (particularly when the target
includes a path), and the subsequent proposal to add user-level target
synonyms, dovetails nicely with the need to reduce the Makefile size.
The synonyms can
Tom == Tom Tromey [EMAIL PROTECTED] writes:
[...]
Tom We have to use subdir-objects
[...]
Tom Also, we use a single top-level Makefile.am
[...]
Tom The problem is, automake generates an explicit rule for each
Tom compilation. Our resulting Makefile.in is nearly 9 megabytes. This
Tom is
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes:
Bob Another thing that would help reduce Makefile size is to
Bob introduce synonyms for subdirectory paths.
Better: LZW compression using Makefile variables. Any taker? wink
--
Alexandre Duret-Lutz
On Tue, 16 Dec 2003, Alexandre Duret-Lutz wrote:
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes:
Bob Another thing that would help reduce Makefile size is to
Bob introduce synonyms for subdirectory paths.
Better: LZW compression using Makefile variables. Any taker? wink
Is this your
Thomas == Thomas Fitzsimmons [EMAIL PROTECTED] writes:
[...]
Thomas One specifc problem I noticed is that automake is
Thomas generating three explicit rules for each target. For
Thomas example, for one .java file, these rules are generated:
[...]
Thomas I would only expect rules for .lo
Save over 80% on
New official drugs approved by FDA
Come In and Visit us
Autoconf 2.59 is now available from the following URLs:
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.59.tar.gz
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.59.tar.bz2
Here are the MD5 checksums:
d4d45eaa1769d45e59dcb131a4af17a0 autoconf-2.59.tar.gz
1ee40f7a676b3cfdc0e3f7cd81551b5f
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl Couldn't we use the (existing) .java.o: inference rule in this
adl case? Actually, is there a difference between `%.o: %.java' and
adl `.java.o:' beside portability? -- I'm not asking about the
adl general % construction, just about
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl Furthermore, generally it does not work to compile both the .o
adl and .lo objects of a source file (in the last example Automake
adl is expected to warn that these files are being built both with
adl and without Libtool), so it sounds
15 matches
Mail list logo
