Hi Akim, * Akim Demaille wrote on Tue, Jun 23, 2009 at 11:52:43AM CEST: > I might have missed the information, but I believe there are no > instruction about handling the dependencies bw libraries are install > time (they all live in the same Makefile.am, and I do not want to > break it).
Well, we don't have an end-all be-all solution to this issue yet. I babbled about an idea to solve this a while ago in <http://thread.gmane.org/gmane.comp.sysutils.automake.general/6164> but never got around to an actual implementation. > I have libfoo that depends on libbar, and both are > installed in different directories. Too bad, install goes in the > wrong order, and libtool fails to relink libfoo which it tries to > install first. Had both been in the same directory, then according > to the code, I just have to define then in lib_LTLIBRARIES in the > right order. Right. > install-execenvLTLIBRARIES: install-libLTLIBRARIES > But of course it does not work: with a simple warning, Automake > throws away its own install rule, "overriden" by mine. My work > around: an > > @ADDITIONAL_DEPENDENCIES@ > > line in Makefile.am which I AC_SUBST with the right content. > > Are there any recommendations on this regard? Yeah, you can avoid changing configure.ac in your workaround by hiding the target name in a variable: inst_execenv_libs = install-execenvLTLIBRARIES $(inst_execenv_libs): install-libLTLIBRARIES But of course you are still invading Automake private namespace, and exploiting the bug that automake does not "see" through variables for rule target names. I suppose that we might break your hack with the Automake version that will finally provide a solution for this. BTW, strictly speaking, you are also missing a opposite workaround for the uninstall rule (just in case your "make uninstall" is racing with, or uses programs that use these libraries, and you have an older, say incompatible, set of libraries lying around as well). Cheers, Ralf
