[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.1 Compile-time and 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.

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:

  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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.1.1 GNU Emacs

Although the Free Software Foundation has many enlightened practices regarding Makefiles and software installation (see see section Other FSF software), Emacs, its flagship program, doesn’t quite follow the rules. In particular, most GNU software allows you to write:

 
make
make install prefix=/usr/local/stow/package

If you try this with Emacs, then the new value for prefix in the ‘make install’ step will cause some files to get recompiled with the new value of prefix wired into them. In Emacs 19.23 and later,(2) the way to work around this problem is:

 
make
make install-arch-dep install-arch-indep prefix=/usr/local/stow/emacs

In 19.22 and some prior versions of Emacs, the workaround was:

 
make
make do-install prefix=/usr/local/stow/emacs

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.1.2 Other FSF software

The Free Software Foundation, the organization behind the GNU project, has been unifying the build procedure for its tools for some time. Thanks to its tools ‘autoconf’ and ‘automake’, most packages now respond well to these simple steps, with no other intervention necessary:

 
./configure options
make
make install prefix=/usr/local/stow/package

Hopefully, these tools can evolve to be aware of Stow-managed packages, such that providing an option to ‘configure’ can allow ‘make’ and ‘make install’ steps to work correctly without needing to “fool” the build process.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.1.3 Cygnus software

Cygnus is a commercial supplier and supporter of GNU software. It has also written several of its own packages, released under the terms of the GNU General Public License; and it has taken over the maintenance of other packages. Among the packages released by Cygnus are ‘gdb’, ‘gnats’, and ‘dejagnu’.

Cygnus packages have the peculiarity that each one unpacks into a directory tree with a generic top-level Makefile, which is set up to compile all of Cygnus’ packages, any number of which may reside under the top-level directory. In other words, even if you’re only building ‘gnats’, the top-level Makefile will look for, and try to build, ‘gdb’ and ‘dejagnu’ subdirectories, among many others.

The result is that if you try ‘make -n install prefix=/usr/local/stow/package’ at the top level of a Cygnus package, you’ll get a bewildering amount of output. It will then be very difficult to visually scan the output to see whether the install will proceed correctly. Unfortunately, it’s not always clear how to invoke an install from the subdirectory of interest.

In cases like this, the best approach is to run your ‘make install prefix=’, but be ready to interrupt it if you detect that it is recompiling files. Usually it will work just fine; otherwise, install manually.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.1.4 Perl and Perl 5 modules

Perl 4.036 allows you to specify different locations for installation and for run-time. It is the only widely-used package in this author’s experience that allows this, though hopefully more packages will adopt this model.

Unfortunately, the authors of Perl believed that only AFS sites need this ability. The configuration instructions for Perl 4 misleadingly state that some occult means are used under AFS to transport files from their installation tree to their run-time tree. In fact, that confusion arises from the fact that Depot, Stow’s predecessor, originated at Carnegie Mellon University, which was also the birthplace of AFS. CMU’s need to separate install-time and run-time trees stemmed from its use of Depot, not from AFS.

The result of this confusion is that Perl 5’s configuration script doesn’t even offer the option of separating install-time and run-time trees unless you’re running AFS. Fortunately, after you’ve entered all the configuration settings, Perl’s setup script gives you the opportunity to edit those settings in a file called ‘config.sh’. When prompted, you should edit this file and replace occurrences of

 
inst/usr/local

with

 
inst/usr/local/stow/perl

You can do this with the following Unix command:

 
sed 's,^\(inst.*/usr/local\),\1/stow/perl,' config.sh > config.sh.new
mv config.sh.new config.sh

Hopefully, the Perl authors will correct this deficiency in Perl 5’s configuration mechanism.

Perl 5 modules—i.e., extensions to Perl 5—generally conform to a set of standards for building and installing them. The standard says that the package comes with a top-level ‘Makefile.PL’, which is a Perl script. When it runs, it generates a ‘Makefile’.

If you followed the instructions above for editing ‘config.sh’ when Perl was built, then when you create a ‘Makefile’ from a ‘Makefile.PL’, it will contain separate locations for run-time (‘/usr/local’) and install-time (‘/usr/local/stow/perl’). Thus you can do

 
perl Makefile.PL
make
make install

and the files will be installed into ‘/usr/local/stow/perl’. However, you might prefer each Perl module to be stowed separately. In that case, you must edit the resulting Makefile, replacing ‘/usr/local/stow/perl’ with ‘/usr/local/stow/module’. The best way to do this is:

 
perl Makefile.PL
find . -name Makefile -print | \
  xargs perl -pi~ -e 's,^(INST.*/stow)/perl,$1/module,;'
make
make install

(The use of ‘find’ and ‘xargs’ ensures that all Makefiles in the module’s source tree, even those in subdirectories, get edited.) A good convention to follow is to name the stow directory for a Perl modulecpan.module’, where ‘cpan’ stands for Comprehensive Perl Archive Network, a collection of FTP sites that is the source of most Perl 5 extensions. This way, it’s easy to tell at a glance which of the subdirectories of ‘/usr/local/stow’ are Perl 5 extensions.

When you stow separate Perl 5 modules separately, you are likely to encounter conflicts (see section Conflicts) with files named ‘.exists’ and ‘perllocal.pod’. One way to work around this is to remove those files before stowing the module. If you use the ‘cpan.module’ naming convention, you can simply do this:

 
cd /usr/local/stow
find cpan.* \( -name .exists -o -name perllocal.pod \) -print | \
  xargs rm

[ < ] [ > ]   [ << ] [ Up ] [ >> ]

This document was generated by Build Daemon user on February 15, 2010 using texi2html 1.82.