automake
[Top][All Lists]
Advanced

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

Re: DESTDIR vs `make install exec_prefix='


From: Harlan Stenn
Subject: Re: DESTDIR vs `make install exec_prefix='
Date: Sat, 18 Apr 2009 20:24:46 +0000

Russ wrote:
> Ralf Wildenhues <address@hidden> writes:
> > [1] I'm asking because Automake 1.11 will reliably not install files if
> > their respective installation directory is empty.  This is not yet
> > functional in Automake 1.10.2.  The test for emptiness in 1.11 will not
> > consider $(DESTDIR) of course, only $(bindir) etc.
> 
> I must have misunderstood this, since it sounds like it would potentially
> break any system where each binary package is installed into a separate
> tree.  For example, stow packages are routinely installed with:
> 
>     ./configure --prefix=/usr/local
>     make
>     make install prefix=/usr/local/stow/package-version
> 
> DESTDIR cannot easily be used here because the stow layout should have
> simple bin, etc, lib, etc. directories directly under that directory, not
> with an extra /usr/local in the way.

I know that GNU coding standards really want package developers to allow
one to be able to override the prefix at "make install" time and "it
should just work".  While I appreciate the goal and sentiment, sometimes
that just isn't easy or feasible to do.

When I build packages for the modules.sourceforge.net project (similar
to stow) I just make a point of running configure with the --prefix set
to the actual installation/execution path.

In this case I may use DESTDIR for one of two purposes:

- I want to install it "somewhere else" so I can tar up that subtree and
  unpack it later into the correct place
- I have to sneak the installation into a different place to install
  under a tree that accomodates am-utils and NFS-mounting the
  executables for a specific target architecture, and I keep all the
  "installed packages" for all the target architectures on a single
  partition.

For me this entire discussion smacks of some "fuzzy edges" between
mechanism (where to put things, and the spsecification of how the code
figure out where to look for things) and policy (where to put things,
and the specification of how the code figure out here to look for
things).

H




reply via email to

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