adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl Also, since we have switched to API-numbering, bumping that
adl version number has a cost. For instance Debian distributes
adl automake1.4, automake1.6, automake1.7, and automake1.8. If we
adl add another API, it'd better be worth it.
Thomas == Thomas Fitzsimmons [EMAIL PROTECTED] writes:
[...]
Thomas I was wondering about the time frame for the next
Thomas release of automake. Our libgcj configury upgrade
Thomas depends on changes that are currently only available in
Thomas automake's CVS HEAD, so we anxiously await an
On Fri, 2004-01-02 at 16:39, Tom Tromey wrote:
Tom == Thomas Fitzsimmons [EMAIL PROTECTED] writes:
[ suggestions ]
Tom Anyway, this patch brings us closer to using automake-1.8 for libgcj.
Tom Thanks!
I think all the patches are in now. Could you try CVS automake and
see how big the
Tom == Thomas Fitzsimmons [EMAIL PROTECTED] writes:
[ suggestions ]
Tom Anyway, this patch brings us closer to using automake-1.8 for libgcj.
Tom Thanks!
I think all the patches are in now. Could you try CVS automake and
see how big the resulting Makefile.in is?
Tom
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl I've found this:
adl 1999-11-22 Tom Tromey [EMAIL PROTECTED]
adl * automake.in (handle_single_transform_list): Generate explicit
adl rule for subdir objects. Fixes new addition to subobj.test.
I looked into this a bit
Tom == Tom Tromey [EMAIL PROTECTED] writes:
[...]
Tom I looked into this a bit today. One nice thing about having a patch
Tom list is that it records the rationale for changes somewhere... back in
Tom those days that sort of information was just lost. Sigh.
I thought so, until I
On Tue, 30 Dec 2003, Alexandre Duret-Lutz wrote:
[EMAIL PROTECTED] is only archived at mail.gnu.org and
gmane.org. It is quite young so the mail.gnu.org archive is
complete, however I fear the day it will be cut.
any idea what fraction of the archive is spam?
--
Thomas E. Dickey
On Sat, 2003-12-27 at 21:25, Alexandre Duret-Lutz wrote:
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
[...]
adl 1999-11-22 Tom Tromey [EMAIL PROTECTED]
adl
adl * automake.in (handle_single_transform_list): Generate explicit
adl rule for subdir objects.
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf On Tue, 2003-12-16 at 17:49, 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
Thomas == Thomas Fitzsimmons [EMAIL PROTECTED] writes:
[...]
Thomas The size could still be reduced further though. I
Thomas discussed the following with Tom on IRC:
Thomas - all libgcj objects are listed in
Thomas am__libgcj_la_SOURCES_DIST which is included in
Thomas DIST_SOURCES.
On Wed, 31 Dec 2003, Alexandre Duret-Lutz wrote:
Hmmm. What we'd need to merge are these:
.c.o:
$(CC) -c -o $@ $
.c.obj:
$(CC) -c -o $@ `$(CYGPATH_W) $`
[stuff removed]
The extension is obviously not an issue, but how can we arrange the CYGPATH_W
stuff?
An simple (but
On Wed, 2003-12-17 at 16:01, Bob Friesenhahn wrote:
On Wed, 17 Dec 2003, Lars Hecking wrote:
What about an automake option then to generate Makefiles for GNU make?
How about a new binary 'automake' program that doesn't require an
external 'make' program at all? It would read the
On Tue, 2003-12-16 at 17:49, 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.
For subdir-compilation/non-recursive Makefiles
On Thu, 18 Dec 2003, Ralf Corsepius wrote:
On Wed, 2003-12-17 at 16:01, Bob Friesenhahn wrote:
On Wed, 17 Dec 2003, Lars Hecking wrote:
What about an automake option then to generate Makefiles for GNU make?
How about a new binary 'automake' program that doesn't require an
external
%% Bob Friesenhahn [EMAIL PROTECTED] writes:
So, IMO, for being useful, you'd either have to extend make to accept
the *.am-syntax or to reimplement make.
bf Exactly. The binary 'automake' would be a plain make which also
bf understands Automake syntax.
bf If a non-standard tool is
Paul D. Smith [EMAIL PROTECTED] writes:
If you're willing to require GNU make then I'm quite confidant you
could write automake as nothing more than a suite of GNU make macros
and functions.
I doubt there would be any need for code changes to GNU make at all.
i think it would be
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes:
Bob 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
Tom == Tom Tromey [EMAIL PROTECTED] writes:
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
Paul D. Smith writes:
%% 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.
%% Lars Hecking [EMAIL PROTECTED] writes:
lh What about an automake option then to generate Makefiles for GNU
lh make?
You might get slightly more takers for an option to allow use of pattern
rules, without specifically tying them to GNU make or relying on other
_very_ GNU make-centric
On Wed, 17 Dec 2003, Lars Hecking wrote:
What about an automake option then to generate Makefiles for GNU make?
How about a new binary 'automake' program that doesn't require an
external 'make' program at all? It would read the Makefile.am files
directly ...
Bob
Greetings,
On Wed, 17 Dec 2003, Bob Friesenhahn wrote:
On Wed, 17 Dec 2003, Lars Hecking wrote:
What about an automake option then to generate Makefiles for GNU make?
How about a new binary 'automake' program that doesn't require an
external 'make' program at all? It would read the
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
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
34 matches
Mail list logo
