Ralf Wildenhues <ralf.wildenh...@gmx.de> 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 += $(ldad...@cu_less@) > > > > @CU_LESS@ is either true or false. > > > > $(ldad...@cu_less@) 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 $(ldad...@cu_less@) $(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) $(ldad...@cu_less@) That way I hope to append the needed deps. Will it break in mysterious ways?