[Top][All Lists]

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

Re: How to install additional files in "make install"

From: Ralf Corsepius
Subject: Re: How to install additional files in "make install"
Date: Sat, 22 Sep 2007 05:10:20 +0200

On Fri, 2007-09-21 at 19:11 +0200, Ralf Wildenhues wrote:
> * Ralf Corsepius wrote on Fri, Sep 21, 2007 at 06:57:04PM CEST:
> > On Fri, 2007-09-21 at 16:10 +0200, Ralf Wildenhues wrote:
> > > > > * Ralf Corsepius wrote on Thu, Sep 20, 2007 at 09:46:12AM CEST:
> [...]
> > > > > | `libdir' is not a legitimate directory for `DATA'
> [...]
> > > I agree that there should be a straightforward way to put files there.
> > > But it is right about complaining about the above line,
> > I disagree. *_DATA should take arbitrary data, no matter what it is and
> > let the user do with it whatever he wants.
> But it's exactly the use case that the original pointer desired, that
> can break in unexpected ways: if you install a library with wrong
> permissions, it's not usable on some systems until the permissions are
> finally fixed.
>   But between the time the library is copied and
> install-data-hook is executed, some program may need this new library,
> for example one of the programs that 'make' executes as part of the
> installation process.
> A similar issue has been observed before, IIRC with the gettext package:
> `libtool --mode=install' used `rm -f && ln -s' rather than first trying
> `ln -sf' for creation of library symlinks; but the `ln' binary happened
> to depend on the library that was being installed, so installation
> failed.
Yes, this can happen when installing something into a running system and
replacing it while they it is in use.

That said, your remark is a strong indication that it might be more
advisable to install a binary shared libraries by *_SCRIPTS, but to use

But more generally speaking, issues similar to this are not limited to
LIBRARIES (nor to libdir) but to all primaries on all directories,
because "make install" is not an atomic operation.

> > IMO, automake is outsmarting itself, here.
> It's preventing users from unobvious bugs.
I don't think so. It only causes users resort to 
usrlib = $(libdir)
usrlib_DATA =

> > > Ultimately, I guess another primary, or a prefix to _LIBRARIES or so,
> > > should be created to allow this sort of thing.
> > I don't think this would be wise.
> Do you have a reason for this?

My point was aiming at automake refusing to install non-*LIBRARIES to
libdir. This is what I consider to be non-helpful.

It doesn't solve anything.


reply via email to

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