I'm installing this on HEAD and branch-1-9.
This is essentially an formated copy of this mail
http://lists.gnu.org/archive/html/bug-automake/2005-01/msg00153.html
from a thread that started here
http://lists.gnu.org/archive/html/bug-automake/2004-12/msg00106.html
2005-02-12 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.in (read_am_file): Define variable containing long
* doc/automake.texi (Hard-Coded Install Paths): New node.
(Extending, Extending aclocal, Python): Link to it.
(Extending): Don't show how to install a file in /etc/ directly,
this is insane.
Index: doc/automake.texi
===================================================================
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.44.2.37
diff -u -r1.44.2.37 automake.texi
--- doc/automake.texi 8 Feb 2005 21:41:53 -0000 1.44.2.37
+++ doc/automake.texi 12 Feb 2005 21:22:53 -0000
@@ -254,6 +254,7 @@
* renamed objects:: Why are object files sometimes renamed?
* Per-Object Flags:: How to simulate per-object flags?
* Multiple Outputs:: Writing rules for tools with many output files
+* Hard-Coded Install Paths:: Installing to Hard-Coded Locations
History of Automake
@@ -1971,6 +1972,11 @@
aclocal_DATA = mymacro.m4 myothermacro.m4
@end example
[EMAIL PROTECTED]
+Please do use @file{$(datadir)/aclocal}, and not something based on
+the result of @code{aclocal --print-ac-dir}. @xref{Hard-Coded Install
+Paths}, for arguments.
+
A file of macros should be a series of properly quoted
@code{AC_DEFUN}'s (@pxref{Macro Definitions, , , autoconf, The
Autoconf Manual}). The @command{aclocal} programs also understands
@@ -5330,7 +5336,8 @@
that the user can run @code{make prefix=/foo install}. The Autoconf
manual has a section with more details on this topic
(@pxref{Installation Directory Variables, , Installation Directory
-Variables, autoconf, The Autoconf Manual}).
+Variables, autoconf, The Autoconf Manual}). See also @ref{Hard-Coded
+Install Paths}.
@node Documentation
@@ -7018,12 +7025,17 @@
use @code{uninstall-local}. It doesn't make sense to uninstall just
data or just executables.
-For instance, here is one way to install a file in @file{/etc}:
+For instance, here is one way to erase a subdirectory during
[EMAIL PROTECTED] clean} (@pxref{Clean}).
[EMAIL PROTECTED]
-install-data-local:
- $(INSTALL_DATA) $(srcdir)/afile $(DESTDIR)/etc/afile
[EMAIL PROTECTED] example
[EMAIL PROTECTED]
+clean-local:
+ -rm -rf testSubDir
[EMAIL PROTECTED] smallexample
+
+Older version of this manual used to show how to use
[EMAIL PROTECTED] to install a file to some hard-coded
+location, but you should avoid this. (@pxref{Hard-Coded Install Paths})
@cindex @code{-hook} targets
@cindex hook targets
@@ -7412,6 +7424,7 @@
* renamed objects:: Why are object files sometimes renamed?
* Per-Object Flags:: How to simulate per-object flags?
* Multiple Outputs:: Writing rules for tools with many output files
+* Hard-Coded Install Paths:: Installing to Hard-Coded Locations
@end menu
@node CVS
@@ -8433,6 +8446,135 @@
portable, but they can be convenient in packages that assume GNU
@command{make}.
+
[EMAIL PROTECTED] Hard-Coded Install Paths
[EMAIL PROTECTED] Installing to Hard-Coded Locations
+
[EMAIL PROTECTED]
+My package needs to install some configuration file. I tried to use
+the following rule, but @code{make distcheck} fails. Why?
+
[EMAIL PROTECTED]
+# Do not do this.
+install-data-local:
+ $(INSTALL_DATA) $(srcdir)/afile $(DESTDIR)/etc/afile
[EMAIL PROTECTED] example
[EMAIL PROTECTED] display
+
[EMAIL PROTECTED]
+My package needs to populate the installation directory of another
+package at install-time. I can easily compute that installation
+directory in @file{configure}, but if I install files therein,
[EMAIL PROTECTED] distcheck} fails. How else should I do?
[EMAIL PROTECTED] display
+
+These two setups share their symptoms: @code{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 (@code{$(prefix)}, @code{$(bindir)},
[EMAIL PROTECTED](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 @code{/usr} or @code{/usr/local}. So he
+does something like @code{./configure --prefix ~/usr} to install
+package in his own @code{~/usr} tree.
+
+If a package attempts to install something to some hard-coded path
+(e.g., @file{/etc/afile}), regardless of this @code{--prefix} setting,
+then the installation will fail. @code{make distcheck} performs such
+a @code{--prefix} installation, hence it will fail too.
+
+Now, there are some easy solutions.
+
+The above @code{install-data-local} example for installing
[EMAIL PROTECTED]/etc/afile} would be better replaced by
+
[EMAIL PROTECTED]
+sysconf_DATA = afile
[EMAIL PROTECTED] smallexample
+
[EMAIL PROTECTED]
+by default @code{sysconfdir} will be @code{$(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
[EMAIL PROTECTED]/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:
+
[EMAIL PROTECTED]
+% @kbd{python -c 'from distutils import sysconfig;
+ print sysconfig.get_python_lib(1,0)'}
+/usr/lib/python2.3/site-packages
[EMAIL PROTECTED] example
+
+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 @code{sysconfig.get_python_lib()} function
+actually accepts a third argument that will replace Python's
+installation prefix.
+
[EMAIL PROTECTED]
+% @kbd{python -c 'from distutils import sysconfig;
+ print sysconfig.get_python_lib(1,0,"[EMAIL PROTECTED]@}")'}
[EMAIL PROTECTED]@}/lib/python2.3/site-packages
[EMAIL PROTECTED] example
+
+You can also use this new path. If you do
[EMAIL PROTECTED] @bullet
[EMAIL PROTECTED]
+root users can install your package with the same @code{--prefix}
+as Python (you get the behavior of the previous attempt)
+
[EMAIL PROTECTED]
+non-root users can install your package too, they will have the
+extension module in a place that is not searched by Python but they
+can work around this using environment variables (and if you installed
+scripts that use this shared library, it's easy to tell Python were to
+look in the beginning of your script, so the script works in both
+cases).
[EMAIL PROTECTED] itemize
+
+The @code{AM_PATH_PYTHON} macro uses similar commands to define
[EMAIL PROTECTED](pythondir)} and @code{$(pyexecdir)} (@pxref{Python}).
+
+Of course not all tools are as advanced as Python regarding that
+substitution of @var{prefix}. So another strategy is to figure the
+part of the of the installation directory that must be preserved. For
+instance here is how @code{AM_PATH_LISPDIR} (@pxref{Emacs Lisp})
+computes @code{$(lispdir)}:
+
[EMAIL PROTECTED]
+$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\)$,[EMAIL
PROTECTED]@}/\1,;p;q;@}' \
+ -e
'/.*\/share\/x*emacs\/site-lisp$/@{s,.*/share/\(x*emacs/site-lisp\),[EMAIL
PROTECTED]@}/\1,;p;q;@}' \
+ conftest.out`
[EMAIL PROTECTED] example
+
+I.e., it just picks the first directory that looks like
[EMAIL PROTECTED]/lib/*emacs/site-lisp} or @file{*/share/*emacs/site-lisp} in
+the search path of emacs, and then substitutes @[EMAIL PROTECTED]@}} or
[EMAIL PROTECTED]@[EMAIL PROTECTED] 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 @command{sed} invocation.
+
+
@node History
@chapter History of Automake
--
Alexandre Duret-Lutz
