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.
Some software packages allow you to specify, at compile-time, separate locations for installation and for run-time. Perl is one such package; see 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. See GNU Emacs, and 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:
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.