[Top][All Lists]

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

Re: Test support for automake

From: Ralf Wildenhues
Subject: Re: Test support for automake
Date: Mon, 14 Feb 2011 06:37:04 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

* NightStrike wrote on Sun, Feb 13, 2011 at 02:10:32PM CET:
> On Sat, Feb 12, 2011 at 4:51 PM, Daily, Jeff A wrote:
> >> I have a non-recursive with which I build a library foo. I
> >> list all my tests (quite a lot) in check_PROGRAMS.
> >>
> >> All those tests should (of course) get as LDADD, but how
> >> exactly do I do that _without_ doing a per-target *_LDADD specification.
> >> Per target specification sounds like a lot of redundancy since all my
> >> _LDADD specification would just be
> >> I'd like to add in only _one_ place.

> > Use the LDADD variable.  It's similar to the AM_* variables e.g.
> > AM_LDFLAGS, AM_CPPFLAGS.  All programs use LDADD for linking unless
> > it is overridden by a maude_LDADD per-target variable.

> It sounds like this is a good use case for support of check_LDADD,
> which of course is going to imply a request for generic x_Y support,
> where x is any prefix (bin, lib, etc) and Y is any suffix (cflags,
> etc).

Such flags are a big problem to get right.

What if
  check_PROGRAMS = foo
  bin_PROGRAMS = foo

happens?  Which rule should win?  I don't think we even forbid this kind
of setup, just like we don't forbid sources being listed for more than
one program or library.

Sticking special flags or LDADDs to specific targets OTOH is always


reply via email to

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