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: Thu, 28 Jan 2010 09:57:51 +0100

Ralf Wildenhues <address@hidden> wrote on 2010/01/28 07:06:01:
>
> * Joakim Tjernlund wrote on Wed, Jan 27, 2010 at 09:08:16AM CET:
> > Ralf Wildenhues wrote on 2010/01/27 08:08:09:
> > >
> > > 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?
>
> Seems like it.  It's not portable to other makes though.
>
> > > > 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?
>
> Yes.  It will break as soon as your Makefile.am changes sufficiently for
> automake to decide that $(am__DEPENDENCIES_2) will be the needed helper
> variable (which can be with just another library created), or the next
> version of Automake decides to use a different internal name altogether.
> IOW, don't rely on such a hack.

Suspected that, but then I am a bit surprised there isn't a way to
just add dependencies in automake.

 Jocke





reply via email to

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