Hi Bruno,
thanks for the report!
* Bruno Haible wrote on Sun, Aug 15, 2010 at 04:52:55PM CEST:
In the Automake documentation, the sections Emacs Lisp, Java, Python
are in a chapter Other GNU Tools, two chapters away from the sections
C++ support, Objective C Support, Assembly Support, Java
[ dropped automake@ ]
* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 10:29:51PM CEST:
From ef90f67c33297b361ac9630fd5fa8be5d2e463d5 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Tue, 17 Aug 2010 19:23:47 +0200
Subject: [PATCH 1/2] Fix typo in manual
Hi Ralf,
Thanks for the review of the spec.
+This example uses wildcards. ...
+...@smallexample
+locale_POTS = po/maude.pot
+po_maude_pot_SOURCES = src/**/*.c
+po_maude_pot_SOURCES_EXCLUDE = src/version.c
+...@end smallexample
Can we omit this for now? It can still be added at a
* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 11:05:25PM CEST:
So is:
* doc/automake.texi (Automatic dependency tracking): Fix typo.
acceptable?
Sure.
OK for maint if you agree.
I agree, and I think I should add your name to the ChangeLog entry.
OK?
No need, but do however pleases
() Ralf Wildenhues ralf.wildenh...@gmx.de
() Tue, 17 Aug 2010 21:33:15 +0200
there are a couple of reasons I'd prefer a
slightly different example: [reasons]
Thanks for the prompt review; i agree redundant overlap is undesirable.
[...] SUFFIXES [...]
Ack.
Can we find a
Den 2010-08-13 19:18 skrev Ralf Wildenhues:
I would like to thank everyone who provided input on this topic.
It certainly helps when considering where to go. One conclusion
from this is that we should get Peter's MSVC support finished
and completed for Automake 1.12 and the next Libtool
I would like to test a new special-purpose compiler
(which is part of a bigger project) using the Automake
simple tests feature. I have two problems:
1) I have not found a way to force recompilation
of all test programs whenever the compiler executable
has changed. Note that we are
At Tuesday 17 August 2010, Roberto Bagnara wrote:
I would like to test a new special-purpose compiler
(which is part of a bigger project) using the Automake
simple tests feature.
I have two problems:
1) I have not found a way to force recompilation
of all test programs whenever the
On 08/17/10 13:26, Stefano Lattarini wrote:
At Tuesday 17 August 2010, Roberto Bagnara wrote:
I would like to test a new special-purpose compiler
(which is part of a bigger project) using the Automake
simple tests feature.
I have two problems:
1) I have not found a way to force recompilation
At Tuesday 17 August 2010, Roberto Bagnara wrote:
On 08/17/10 13:26, Stefano Lattarini wrote:
At Tuesday 17 August 2010, Roberto Bagnara wrote:
I would like to test a new special-purpose compiler
(which is part of a bigger project) using the Automake
simple tests feature.
I have two
On 08/17/10 14:26, Stefano Lattarini wrote:
Obviously you're right, sorry for not thinking this through.
If every test program is built from a single `.c' file, what
about using this instead:
$(TESTS:=.o) your-special-purpose-compiler
It should also be portable make AFAIK.
Yes!
TESTS_OBJS
Just a quick follow-up...
If every test program is built from a single `.c' file, what
about using this instead:
$(TESTS:=.o) your-special-purpose-compiler
Or better again, to be even more portable:
$(TESTS:=.$(OBJEXT)) your-special-purpose-compiler
Regards,
Stefano
* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 02:26:13PM CEST:
At Tuesday 17 August 2010, Roberto Bagnara wrote:
On 08/17/10 13:26, Stefano Lattarini wrote:
$(TESTS): your-special-purpose-compiler
That dependency cases relinking whenever the compiler
changes, whereas I need
At Tuesday 17 August 2010, Ralf Wildenhues wrote:
If every test program is built from a single `.c' file, what
about using this instead:
$(TESTS:=.o) your-special-purpose-compiler
It should also be portable make AFAIK.
This doesn't take into account that object file names are an
[ automake-patches@ added; followups can drop automake@ ]
Hello Thien-Thi,
* Thien-Thi Nguyen wrote on Mon, Aug 16, 2010 at 02:22:31AM CEST:
() Ralf Wildenhues
() Sun, 15 Aug 2010 23:32:44 +0200
Yes, with a general example, please.
I am unsure what general example means, precisely, so
* Bob Friesenhahn wrote on Mon, Aug 16, 2010 at 05:06:40PM CEST:
If depending on GNU make was considered ok, then Automake would have
been developed quite differently than it is. Given current Automake
objectives, it is wise that individual projects also try to avoid
GNU make syntax in
[From a discussion on autom...@gnu.org]
At Tuesday 17 August 2010, Roberto Bagnara wrote:
On 08/17/10 13:26, Stefano Lattarini wrote:
At Tuesday 17 August 2010, Roberto Bagnara wrote:
I would like to test a new special-purpose compiler
(which is part of a bigger project) using the Automake
* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 09:37:22PM CEST:
At this point I can think only of two ways out:
I'd go with the previous solution or use the *_OBJECTS variables.
It's not likely that they change.
As an aside: Ralf, do you think this variables are stable enough to be
At Tuesday 17 August 2010, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 09:37:22PM CEST:
At this point I can think only of two ways out:
I'd go with the previous solution or use the *_OBJECTS variables.
It's not likely that they change.
But this would involve a lot
On Tue, Aug 17, 2010 at 10:05:31PM +0200, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Mon, Aug 16, 2010 at 05:06:40PM CEST:
If depending on GNU make was considered ok, then Automake would have
been developed quite differently than it is. Given current Automake
objectives, it is wise
Ralf == Ralf Wildenhues ralf.wildenh...@gmx.de writes:
Ralf If Automake were only started now, I think requiring GNU make
Ralf would be a prudent design decision.
Yeah. Portability looked a lot more important back then. Nowadays I
think assuming GNU make is completely reasonable. You can
On Tue, 17 Aug 2010, Tom Tromey wrote:
Ralf == Ralf Wildenhues ralf.wildenh...@gmx.de writes:
Ralf If Automake were only started now, I think requiring GNU make
Ralf would be a prudent design decision.
Yeah. Portability looked a lot more important back then. Nowadays I
think assuming GNU
I for one would be glad if automake required GNU make, since it
could make use of a lot of useful features which currently aren't
allowed. Similar to autoconf not requiring a POSIX shell, depite
the fact that non-POSIX shells are so far obsolete they are
irrelevant.
Are there any tools to
Hi Tom,
* Tom Tromey wrote on Wed, Aug 18, 2010 at 12:21:19AM CEST:
The make part of the build parallelizes well, but the configure part
does not.
Yet.
I think that is the big problem today. It is particularly
noticeable in big trees like gcc or gdb.
Both of whose build systems could use
24 matches
Mail list logo
