Hi Krzesimir, thanks for the report and sorry for the awful delay. On Thursday 18 August 2011, Krzesimir Nowak wrote: > Package: automake > Version: 1.11.1 > > It would be useful to add a note to "8.4 Program and Library Variables" > part of Automake documentation that Automake's dependency generator does > not generate proper dependencies when maude_LIBADD have variables that > are AC_SUBSTed. In such case maude_DEPENDENCIES should be used > explicitly. > But that would also override the dependencies automatically computed by automake ... (which might not be a problem in your case, but it might be in the general case).
And that's why, in the developement varsion of automake, we have (well, Ralf has, actually) introduced support for `EXTRA_maude_DEPENDENCIES', that allows one to *extend* the automake-computed dependencies, instead of simply override them. This new variable would be perfect for your use case. The relevant commit is `v1.11-377-g6edafbb': <http://git.savannah.gnu.org/cgit/automake.git/commit/?id=6edafbb> > If this is a bug then please see an example in attached tarball. > It contains code for two simple libraries - hello and greeter. Greeter > depends on hello. There is a file greeter/greeter.am in which I have > written _LIBADD and _DEPENDENCIES in several ways - the first two tries > ends with linking error stating about nonexistent libhello.la. Please > also note that I used a nonrecursive Automake and Makefile.am includes > greeter.am first and then hello.am (so in a sort of reverse order). If > hello.am would be included first and then greeter.am - compilation then > usually passes when compiling it in single thread. > I can reproduce the failure with your example; and using the developement version of automake (master branch) I can fix it using the following in `greeter/greeter.am': greeter_libgreeter_la_LIBADD = $(HELLO_LIBS) EXTRA_greeter_libgreeter_la_DEPENDENCIES = $(HELLO_LIBS) > If this is not a bug I am willing to provide a patch dor documentation. > It's a limitation rather than a bug; and the workaround with EXTRA_foo_DEPENDENCIES that I've explained above is the documented, "kosher" way around it. Still, I can see that the documentation in is not as clear as it could be in this matter; so feel free to submit a documentation patch (against master), and we will surely consider it. Thanks, Stefano
