[Top][All Lists]

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


From: Ralf Wildenhues
Subject: Re: check_PROGRAMS & LDADD
Date: Sat, 23 Oct 2010 09:43:23 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hello Patrick,

please don't top-post, thank you.

* Patrick M. Rutkowski wrote on Thu, Oct 21, 2010 at 11:55:28PM CEST:
> On Thu, Oct 21, 2010 at 4:17 PM, NightStrike wrote:
> > On Wed, Oct 20, 2010 at 1:01 AM, Ralf Wildenhues wrote:
> >> * Patrick Rutkowski wrote on Wed, Oct 20, 2010 at 03:26:52AM CEST:
> >>> As the collection of tests grows it's going to get annoying to have to
> >>> add an _LDADD entry for every single one separately. Is it possible to
> >>> add an _LDADD for all check_PROGRAMS items in one blow?
> >>
> >> All *_PROGRAMS that don't have an *_LDADD override use plain LDADD:
> >>
> >> LDADD = -lquark
> >
> > Is there any _PROGRAM that isn't a check_PROGRAM?
> Good question. At this very moment, no, there aren't any other programs.
> But there might potentially be other programs in the future. And I'd
> still really love to know if there's less blanket-cover way to do it
> than the global LDADD.

At that point you can either specify all check programs in a separate, say tests/, and set LDADD differently in that,
or you can set the <prog>_LDADD for one or both of the sets.

Currently, check_PROGRAMS, bin_PROGRAMS, and noinst_PROGRAMS only differ
in *when* their rules are triggered, not in how they are built when they
are built.  I really would like to keep it that way, because everything
else is fairly insane wrt. implementation (cf. lib_LTLIBRARIES vs.
pkglib_LTLIBRARIES which need '-rpath <target_dir>' passed), esp. when
it comes to things like conditionals.

Hope that helps.


reply via email to

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