[ On , September 6, 2000 at 21:57:04 (-0700), Russ Allbery wrote: ]
> Subject: Re: HTML format documentation
>
> Paul D Smith <[EMAIL PROTECTED]> writes:
> > %% Alexandre Oliva <[EMAIL PROTECTED]> writes:
> 
> >>> * Is the advantage big enough to justify the incompatible change
> >>> of saying "You can't specify the prefix when you run Make"?
> 
> > This should always be explicitly _allowed_ during "make install", as
> > long as "make" has been done first.
> 
> > Either that, or DESTDIR should become a required feature of GNU
> > installation.
> 
> You need both; 

Actually no, as I tried to explain earlier you do not want to be able to
adjust $(prefix) during any "make" execution, at least not the way many
people use $(prefix) in existing packages -- as we've seen this is very
bad for dependency maintenance (i.e. it makes it impossible with any
portable makefile that can be written today).

> they don't do the same thing.  The second is less useful;
> it's mostly for installing into a root disk mounted on another file system
> and that sort of thing.  Resetting prefix doesn't do the same thing as
> setting DESTDIR and is considerably more important for some installation
> environments, such as AFS.

However you are correct in stating that $(prefix) and ${DESTDIR} are
very different in what they do.  Indeed it should be possible to adjust
${DESTDIR} during "make install" (and it would only have effect during
"make install").  $(prefix) specifies the *run-time* location of
installed files, not necessarily the location they are installed to.

Now a purist might point out that if you configure a package with:

        --prefix=/usr/local

and then install with:

        mkdir -p /var/tmp/foopackage/usr/local
        make install prefix=/var/tmp/foopackage/usr/local

and then move the package to the target machine with something like:

        cd /var/tmp/foopackage
        tar -czf - | rsh runmachine tar -xzf -

the right things should always happen w.r.t. installation locations and
run-time locations.

The problem with this is that it it is extremely confusing to developers
and users alike (as can be demonstrated by analysis of many existing
packages).  Clearly separating the intent of variables that specify
installation locations and run-time locations is far more productive
than their current overloaded state.

> There was some discussion of this on the list a while back.

hmmm....

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <[EMAIL PROTECTED]>      <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

Reply via email to