automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dependencies bw LTLIBRARIES at install time


From: Ralf Wildenhues
Subject: Re: Dependencies bw LTLIBRARIES at install time
Date: Tue, 23 Jun 2009 20:55:21 +0200
User-agent: Mutt/1.5.20 (2009-06-15)

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




reply via email to

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