automake
[Top][All Lists]
Advanced

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

Re: dependencies with @xx@ variables


From: Joakim Tjernlund
Subject: Re: dependencies with @xx@ variables
Date: Wed, 27 Jan 2010 09:08:16 +0100

Ralf Wildenhues <address@hidden> wrote on 2010/01/27 08:08:09:
>
> Hello Joakim,
>
> * Joakim Tjernlund wrote on Tue, Jan 26, 2010 at 02:20:24PM CET:
> >
> > I got this rule in Makfile.am:
> >  ldadds_false = $(ldadds_cuappl)
> >  ldadds_true = $(ldadds_culess)
> >
> >  common_LDADD += $(address@hidden@)
> >
> > @CU_LESS@ is either true or false.
> >
> > $(address@hidden@) is omitted in am__DEPENDENCIES_1 so
> > if any lib mentioned in ldadds_cuappl or ldadds_culess changes
> > no rebuild is generated.
> >
> > if I change $(address@hidden@) $(ldadds_false) it makes it into
> > am__DEPENDENCIES_1 and a rebuild is generated.
> >
> > Is the above a bug?
>
> No.  When automake cannot see a literal in a *_LDADD or *_LIBADD
> statement, it cannot interpolate it to the respective *_DEPENDENCIES
> variable: non-literal content might expand to stuff like '-lm' or
> '-L/foo' which would cause 'make' to barf if listed as prerequisites
> somewhere.

I see, I tried setting *_DEPENDENCIES to *_LDADD and that worked
even though *_LDADD contains -lm and as I read your stmt above it
should barf on -lm. Can GNU make handle this?

>
> > How do I workaround it?
>
> Build the *_DEPENDENCIES variable yourself.  You have to take care of
> all of its entries if you do so, it overwrites, not appends to, any
> automake-computed library dependencies.

Would it be terribly bad if I did:
 *_DEPENDENCIES = $(am__DEPENDENCIES_1) $(address@hidden@)
That way I hope to append the needed deps. Will it break in
mysterious ways?





reply via email to

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