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:=...@objext@): compiler
>
> is. Also, if your tests contain scripts as well,
> $(check_PROGRAMS:=...@objext@): 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
