Re: automake -vs- huge projects

2003-12-16 Thread Tom Tromey
> "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

Re: automake -vs- huge projects

2003-12-16 Thread Tom Tromey
> "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, ju

Re: automake -vs- huge projects

2003-12-16 Thread Alexandre Duret-Lutz
>>> "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 f

Re: automake -vs- huge projects

2003-12-16 Thread Bob Friesenhahn
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? Is

Re: automake -vs- huge projects

2003-12-16 Thread Alexandre Duret-Lutz
>>> "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? -- Alexandre Duret-Lutz

cialis is the new drug

2003-12-16 Thread Vito Butcher
Save over 80% on New official drugs approved by FDA Come In and Visit us

Re: automake -vs- huge projects

2003-12-16 Thread Alexandre Duret-Lutz
>>> "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

Autoconf 2.59 available from ftp.gnu.org

2003-12-16 Thread Paul Eggert
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 autoconf-2.59.tar.

Re: automake -vs- huge projects

2003-12-16 Thread Bob Friesenhahn
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 hel

Re: automake -vs- huge projects

2003-12-16 Thread Bob Friesenhahn
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 nam

Re: automake -vs- huge projects

2003-12-16 Thread Thomas Fitzsimmons
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

Re: automake -vs- huge projects

2003-12-16 Thread Bob Friesenhahn
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 defau

Re: automake -vs- huge projects

2003-12-16 Thread Paul D. Smith
%% 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 conti

Re: automake -vs- huge projects

2003-12-16 Thread Bob Friesenhahn
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 de

automake -vs- huge projects

2003-12-16 Thread Tom Tromey
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 1.