Previous: Multiple Outputs, Up: FAQ
My package needs to install some configuration file. I tried to use the following rule, but ‘make distcheck’ fails. Why?# Do not do this. install-data-local: $(INSTALL_DATA) $(srcdir)/afile $(DESTDIR)/etc/afile
My package needs to populate the installation directory of another package at install-time. I can easily compute that installation directory in configure, but if I install files therein, ‘make distcheck’ fails. How else should I do?
These two setups share their symptoms: ‘make distcheck’ fails because they are installing files to hard-coded paths. In the later case the path is not really hard-coded in the package, but we can consider it to be hard-coded in the system (or in whichever tool that supplies the path). As long as the path does not use any of the standard directory variables (‘$(prefix)’, ‘$(bindir)’, ‘$(datadir)’, etc.), the effect will be the same: user-installations are impossible.
When a (non-root) user wants to install a package, he usually has no right to install anything in /usr or /usr/local. So he does something like ‘./configure --prefix ~/usr’ to install package in his own ~/usr tree.
If a package attempts to install something to some hard-coded path (e.g., /etc/afile), regardless of this --prefix setting, then the installation will fail. ‘make distcheck’ performs such a --prefix installation, hence it will fail too.
Now, there are some easy solutions.
The above install-data-local
example for installing
/etc/afile would be better replaced by
sysconf_DATA = afile
by default sysconfdir
will be ‘$(prefix)/etc’, because
this is what the GNU Standards require. When such a package is
installed on a FHS compliant system, the installer will have to set
‘--sysconfdir=/etc’. As the maintainer of the package you
should not be concerned by such site policies: use the appropriate
standard directory variable to install your files so that installer
can easily redefine these variables to match their site conventions.
Installing files that should be used by another package, is slightly more involved. Let's take an example and assume you want to install shared library that is a Python extension module. If you ask Python where to install the library, it will answer something like this:
% python -c 'from distutils import sysconfig; print sysconfig.get_python_lib(1,0)' /usr/lib/python2.3/site-packages
If you indeed use this absolute path to install your shared library, non-root users will not be able to install the package, hence distcheck fails.
Let's do better. The ‘sysconfig.get_python_lib()’ function actually accepts a third argument that will replace Python's installation prefix.
% python -c 'from distutils import sysconfig; print sysconfig.get_python_lib(1,0,"${exec_prefix}")' ${exec_prefix}/lib/python2.3/site-packages
You can also use this new path. If you do
The AM_PATH_PYTHON
macro uses similar commands to define
‘$(pythondir)’ and ‘$(pyexecdir)’ (see Python).
Of course not all tools are as advanced as Python regarding that
substitution of prefix. So another strategy is to figure the
part of the of the installation directory that must be preserved. For
instance, here is how AM_PATH_LISPDIR
(see Emacs Lisp)
computes ‘$(lispdir)’:
$EMACS -batch -q -eval '(while load-path (princ (concat (car load-path) "\n")) (setq load-path (cdr load-path)))' >conftest.out lispdir=`sed -n -e 's,/$,,' -e '/.*\/lib\/x*emacs\/site-lisp$/{ s,.*/lib/\(x*emacs/site-lisp\)$,${libdir}/\1,;p;q; }' -e '/.*\/share\/x*emacs\/site-lisp$/{ s,.*/share/\(x*emacs/site-lisp\),${datarootdir}/\1,;p;q; }' conftest.out`
I.e., it just picks the first directory that looks like */lib/*emacs/site-lisp or */share/*emacs/site-lisp in the search path of emacs, and then substitutes ‘${libdir}’ or ‘${datadir}’ appropriately.
The emacs case looks complicated because it processes a list and expect two possible layouts, otherwise it's easy, and the benefit for non-root users are really worth the extra sed invocation.