On Thu, Jan 22, 2004 at 04:54:33PM -0700, Tom Tromey wrote:
> > "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, aut
> "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
>>> "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 anxiousl
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 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 an
> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes:
Paul> If you're willing to require GNU make then I'm quite confidant
Paul> you could write automake as nothing more than a suite of GNU
Paul> make macros and functions.
Yeah. One idea for the post-auto* world is "let's beef up GNU make
and
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>> $(CC) -c -o $@ `$(CYGPATH_W) $<`
Bob> An simple (but ugly) approach would be to define $(CYGPATH_W) to
Bob> 'echo' when not compiling under Cygwin.
We already have much worse hacks. But ideally we'd be reducing the
amount of weird co
> "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
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
>>> "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_SO
>>> "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 w
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 s
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
http://i
>>> "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
> "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 in
>>> "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. Fixes new addition to subobj.test.
[...]
adl> The othe
%% Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
tn> i think it would be cool if automake supported GNU make
tn> specifically, creating GNUmakefile.in from GNUmakefile.am. a
tn> GNUmakefile.am would imply some automake option "gnu-make-only",
tn> while automake option "gnu-make" would crea
"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 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-standa
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 a
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 auto
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
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 rea
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
%% 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 fe
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> Make
>>> "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? --
>>> "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.
>>
>>
> "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
> "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
>>> "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
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
>>> "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
>>> "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
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
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
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
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
%% 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
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
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.
41 matches
Mail list logo
