On 08/18/10 20:34, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Wed, Aug 18, 2010 at 03:42:01PM CEST:
On Wednesday 18 August 2010, Roberto Bagnara wrote:
On 08/18/10 13:18, Stefano Lattarini wrote:
At Wednesday 18 August 2010, Roberto Bagnara wrote:
#$(TESTS:=...@objext@):
Hello Ralf.
On Wednesday 18 August 2010, Ralf Wildenhues wrote:
I suppose automake could be enhanced to also define $(OBJECTS) as
the set of all objects.
What about libtool objects? Should we care about them? I'm writing a
couple of (xfailing) testcases to check a prospective patch
* Stefano Lattarini wrote on Thu, Aug 19, 2010 at 04:39:29PM CEST:
On Wednesday 18 August 2010, Ralf Wildenhues wrote:
I suppose automake could be enhanced to also define $(OBJECTS) as
the set of all objects.
What about libtool objects? Should we care about them? I'm writing a
couple of
On Thursday 19 August 2010, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Thu, Aug 19, 2010 at 04:39:29PM CEST:
On Wednesday 18 August 2010, Ralf Wildenhues wrote:
I suppose automake could be enhanced to also define $(OBJECTS)
as the set of all objects.
What about libtool
On 08/17/2010 08:47 PM, Ralf Wildenhues wrote:
* 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
At Wednesday 18 August 2010, Roberto Bagnara wrote:
Dear Stefano and Ralf,
thank you very much for your assistance. I am a bit
confused; here is what I have in my Makefile.am
# This does not work: Automake 1.11 rejects it with
# Makefile.am:1148: bad characters in variable name
On 08/18/10 13:18, Stefano Lattarini wrote:
At Wednesday 18 August 2010, Roberto Bagnara wrote:
# This does not work: when ../../bin/compiler changes, tests are
# not recompiled.
# TESTS_OBJS = $(TESTS:=...@objext@)
Typo here (and in Ralf example): should be $(TESTS:=...@objext@),
with a dot
On Wednesday 18 August 2010, Roberto Bagnara wrote:
On 08/18/10 13:18, Stefano Lattarini wrote:
At Wednesday 18 August 2010, Roberto Bagnara wrote:
# This does not work: when ../../bin/compiler changes, tests are
# not recompiled.
# TESTS_OBJS = $(TESTS:=...@objext@)
Typo here (and
* Stefano Lattarini wrote on Wed, Aug 18, 2010 at 03:42:01PM CEST:
On Wednesday 18 August 2010, Roberto Bagnara wrote:
On 08/18/10 13:18, Stefano Lattarini wrote:
At Wednesday 18 August 2010, Roberto Bagnara wrote:
#$(TESTS:=...@objext@): ../../bin/compiler
The above is rejected
[ 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
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
[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
21 matches
Mail list logo
