bug-libtool
[Top][All Lists]
Advanced

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

Re: finish mode needed for plugins?


From: Ralf Wildenhues
Subject: Re: finish mode needed for plugins?
Date: Mon, 27 Oct 2008 22:13:19 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

* Stefan Kost wrote on Mon, Oct 27, 2008 at 10:01:33PM CET:
> Ralf Wildenhues schrieb:
> >> project - we have several hundreds on modules and each has a single build 
> >> directory.
> > 
> > And each of them has a separate Makefile.am, as opposed to: just a
> > fragment included by another Makefile.am, doing something like
> >    pkglib_LTLIBRARIES += module42.la
> 
> that would work. good idea.

If that's sufficient for you, then we don't need the rest of the
proposal.

> > 2) add an option '--no-finish' to 'libtool --mode=install' to avoid
> > finish_cmds.  This could be useful not only for modules, but libraries
> > as well.  You could enable it in all but the last directory in which
> > you install modules, for example (iff there is a fixed such last one),
> > or manually add an install-exec-hook someplace run late, that does
> >   libtool --mode=finish $(pkglibdir)...
> > 
> > iff DESTDIR is empty (and only in that case!).  Hmm, maybe we should
> > even transport DESTDIR to such a finish command, to allow libtool to
> > output the warning for users.
> > 
> > This change would have the added advantage that automake could, in its
> > install rule, use -no-finish for all invocations but the last one within
> > a single installation rule (this bit is only relevant if there is a
> > directory with very many libraries/modules to install into the same
> > directory.)

> I think you lost me a bit on the DESTDIR proposal. About "DESTDIR" you
> mean the variable beeing empty or the directory beeing empty? I guess
> its the var. This would still only help if we install multiple files
> in one go.

I mean the makefile macro $(DESTDIR).

Well, maybe I should have expanded more.  What happens with current
libtool is this: at the end of each
  $(LIBTOOL) --mode=install $(INSTALL) libfoo.la... $(DESTDIR)$(libdir)...

execution, libtool executes finish_cmds for $(libdir), iff DESTDIR is
empty.  (It uses extra knowledge gained from the .la files to find out
whether DESTDIR is empty.)

If DESTDIR happens to be not empty, then it does not run finish_cmds but
warns the user that she has to do this herself, once libraries appear in
their final locations.


> I see two ways:
> 
> 1) The project requests libtool to not run finish_cmds. Not so nice as this
> might break on some platform. Atleast the project would need to be able to run
> libtool --mode=finish manualy then.

Well.  I do not intend for projects to not run finish_cmds *at all*.
However, they may know that they have 15 directories which install stuff
into $(libdir), and wish to only run finish_cmds *once*, afterwards.

That's the lever I wanted to allow.

By giving this flexibility out to users comes the responsibility though
to
* ensure that --mode=finish is run afterwards,
* but only once libraries are in their final location (i.e., the
  makefile may not run it when $(DESTDIR) is nonempty, but should warn).

Your confusion is a good hint that we should not expose this
functionality to developers, because the potential for wrong
use is too high.

> 2) When configuring libtool for a certain platform, it could disable finish
> commands for modules for platforms where its known to be safe. There could be 
> a
> configure option to --finish-cmds-for-modules={on|off|auto}, so that an admin
> could turn it always on if its needed.

I disagree.  On systems where finish_cmds are unneeded, they should
simply be empty.  There is no point the package developer could be
smarter than libtool here, right?

Cheers,
Ralf




reply via email to

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