(stow.info)Compile-time vs Install-time

---

Next: Bootstrapping Prev: Resource Files Up: Top

---

Enter node , (file) or (file)node

12 Compile-time vs Install-time
*******************************

Software whose installation is managed with Stow needs to be installed
in one place (the package directory, e.g. `/usr/local/stow/perl') but
needs to appear to run in another place (the target tree, e.g.,
`/usr/local').  Why is this important?  What's wrong with Perl, for
instance, looking for its files in `/usr/local/stow/perl' instead of in
`/usr/local'?

   The answer is that there may be another package, e.g.,
`/usr/local/stow/perl-extras', stowed under `/usr/local'.  If Perl is
configured to find its files in `/usr/local/stow/perl', it will never
find the extra files in the `perl-extras' package, even though they're
intended to be found by Perl.  On the other hand, if Perl looks for its
files in `/usr/local', then it will find the intermingled Perl and
`perl-extras' files.

   This means that when you compile a package, you must tell it the
location of the run-time, or target tree; but when you install it, you
must place it in the stow tree.

12.1 Advice on changing compilation and installation parameters
===============================================================

Some software packages allow you to specify, at compile-time, separate
locations for installation and for run-time.  Perl is one such package;
see Note: Perl and Perl 5 Modules.  Others allow you to compile the
package, then give a different destination in the `make install' step
without causing the binaries or other files to get rebuilt.  Most GNU
software falls into this category; Emacs is a notable exception.  Note:
GNU Emacs, and Note: Other FSF Software.

   Still other software packages cannot abide the idea of separate
installation and run-time locations at all.  If you try to `make
install prefix=/usr/local/stow/FOO', then first the whole package will
be recompiled to hardwire the `/usr/local/stow/FOO' path.  With these
packages, it is best to compile normally, then run `make -n install',
which should report all the steps needed to install the just-built
software.  Place this output into a file, edit the commands in the file
to remove recompilation steps and to reflect the Stow-based
installation location, and execute the edited file as a shell script in
place of `make install'.  Be sure to execute the script using the same
shell that `make install' would have used.

   (If you use GNU Make and a shell [such as GNU bash] that understands
`pushd' and `popd', you can do the following:

  1. Replace all lines matching `make[N]: Entering directory DIR' with
     `pushd DIR'.

  2. Replace all lines matching `make[N]: Leaving directory DIR' with
     `popd'.

  3. Delete all lines matching `make[N]: Nothing to be done for RULE'.

   Then find other lines in the output containing `cd' or `make'
commands and rewrite or delete them.  In particular, you should be able
to delete sections of the script that resemble this:

     for i in DIR_1 DIR_2 ...; do \
       (cd $i; make ARGS ...) \
     done

Note, that's "should be able to," not "can."  Be sure to modulate these
guidelines with plenty of your own intelligence.

   The details of stowing some specific packages are described in the
following sections.

GNU Emacs

Other FSF Software

Cygnus Software

Perl and Perl 5 Modules