[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dependencies with @xx@ variables
From: |
Ralf Wildenhues |
Subject: |
Re: dependencies with @xx@ variables |
Date: |
Thu, 28 Jan 2010 07:06:01 +0100 |
User-agent: |
Mutt/1.5.20 (2009-10-28) |
* 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.
Cheers,
Ralf