GNOME Bugzilla – Bug 307062
configure produces bad pam install directory
Last modified: 2005-06-10 18:14:16 UTC
./autogen.sh make make install result is: PAM_PREFIX = NONE/etc problem is $sysconfdir is expanded before $prefix is defined. $prefix (and several other variables) have a dummy value == 'NONE' and don't get defined till the very end of configure. The existing code will work only if prefix is passed as an argument to configure. The solution is to defer expansion. I will provide a patch shortly and check into CVS, just logging this as a known problem and if there was any intended use of early expansion via: PAM_PREFIX=`eval echo $PAM_PREFIX_UNEXPANDED` to allow folks to comment on its purpose.
I think this is what is needed: diff -u -r1.33 configure.ac --- configure.ac 18 May 2005 16:12:56 -0000 1.33 +++ configure.ac 9 Jun 2005 22:25:37 -0000 @@ -89,11 +89,10 @@ AC_MSG_RESULT("PAM files will be installed in prefix ${withval}.") fi]) if test x$withval != x; then - PAM_PREFIX_UNEXPANDED="$withval" + PAM_PREFIX="$withval" else - PAM_PREFIX_UNEXPANDED="$sysconfdir" + PAM_PREFIX='${sysconfdir}' fi -PAM_PREFIX=`eval echo $PAM_PREFIX_UNEXPANDED` AC_SUBST(PAM_PREFIX)
(Note, this problem only occurs when you don't pass --prefix to configure) I can't remember why I wanted PAM_PREFIX to be fully expanded, but I can see why $EXPANDED_SABAYON_DIR needs to be expanded early - its for: admin-tool/sabayon.console.in:2:PROGRAM=@EXPANDED_SABAYON_DIR@/sabayon So, you're fix is probably fine in practice, but its trivial to fix early expansion ... there's a block of code for figuring out the real value of prefix if its NONE, so: 2005-06-10 Mark McLoughlin <markmc@redhat.com> Fix for bug #307062 - when you run configure with no --prefix, PAM_PREFIX ends up defined as "NONE/etc" * configure.ac: move a block of code up to where it belongs. Note, all this stuff is just copied from GDM: http://cvs.gnome.org/viewcvs/*checkout*/gdm2/configure.in
Thanks for your fix Mark. This isn't a big issue, but I'm not sure its correct even if GDM does it. The GNU coding standard says variables dependent on prefix or exec_prefix are not supposed to be expanded in configure (see below). The fix checked into CVS produces Makefiles that have a mix of "position independent" installation variables (those containing $(prefix)) and fully expanded hardcoded installation directories. This will yield inconsistent (and frustrating) results if one does a "make install prefix=XXX" which is supposed to work (the resulting configure script even promises it will work). From the GNU Autoconf manual: Most of these variables have values that rely on prefix or exec_prefix. It is deliberate that the directory output variables keep them unexpanded: typically `@datadir@' will be replaced by `${prefix}/share', not `/usr/local/share'. This behavior is mandated by the GNU coding standards, so that when the user runs: `make' she can still specify a different prefix from the one specified to configure, in which case, if needed, the package shall hard code dependencies corresponding to the make-specified prefix. `make install' she can specify a different installation location, in which case the package must still depend on the location which was compiled in (i.e., never recompile when `make install' is run). This is an extremely important feature, as many people may decide to install all the files of a package grouped together, and then install links from the final locations to there. In order to support these features, it is essential that datadir remains being defined as `${prefix}/share' to depend upon the current value of prefix.