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: Stefano Lattarini
Subject: Re: Testing a new compiler with Automake "simple tests"
Date: Tue, 17 Aug 2010 21:37:22 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

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
> 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.
Nice catch, I keep forgotting that.

At this point I can think only of two ways out:
  1. Ensure that no object files' renaming takes place, by writing
     the `tests/Makefile.am' carefully.  This means in particular
     that per-target flags cannot be used, which, depending on the
     situation, might or might not be a serious limit.
  2. Re-enable automatic dependency tracking also for test programs,
     and make *every* source file used by these programs include a
     dummy header file which is updated every time the compiler under
     test is modified.  Yuck.

> I'm mentioning @OBJEXT@ because
>   $(TESTS:=$(OBJEXT)): compiler
> 
> is not portable to some make implementations,
Sorry, didn't know that; I can test only with GNU make, Solaris make 
and FreeBSD make.  They all worked with my snippet.
> 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).
As an aside: Ralf, do you think this variables are stable enough to be 
documented?  If yes, do you think doing so would be worthwhile?

Regards,
   Stefano



reply via email to

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