automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Testing a new compiler with Automake "simple tests"


From: Ralf Wildenhues
Subject: Re: Testing a new compiler with Automake "simple tests"
Date: Tue, 17 Aug 2010 20:47:03 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

* 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 recompilation.
> 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.

This doesn't take into account that object file names are an internal
detail of Automake.  In practice, they might end in .obj, as Stefano
already noted, which $(OBJEXT) or @OBJEXT@ can tell you, but also,
object files may be renamed due to one of several reasons such as
per-target flags, (obsolete) KnR support, and others.

I'm mentioning @OBJEXT@ because
  $(TESTS:=$(OBJEXT)): compiler

is not portable to some make implementations, while
  $(TESTS:address@hidden@): compiler

is.  Also, if your tests contain scripts as well,
  $(check_PROGRAMS:address@hidden@): compiler

or EXTRA_PROGRAMS may be more correct.


There are usually undocumented variables which hold the lists of objects
which you could use but then be forced to check whether updating to a
new Automake might have broken things (unlikely case, but possible).

> > Do you know if there is a way I can force Automake
> > to add a dependency on the compiler in the .c.o rule?
> > That is, to generate:
> > 
> > .c.o:       my-special-purpose-compiler
> >     $(AM_V_CC) \
> >     $(COMPILE) -c $<
> > 
> No, sorry; I don't even think it's possible (but I'm not sure about 
> it, either).

FWIW, it is not portable to all make implementations to specify
dependencies to an inference rule.  It should be done separately.

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]