>>>>> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Alexandre> Of course, sometimes it's convenient to change these
Alexandre> options at build time, but the potential for trouble is
Alexandre> such that I wouldn't recommend this practice.
Akim> I would even prevent this practice, make it invalid.
Richard> I am not sure exactly which practice you and Alexandre are
Richard> talking about. But making something invalid which used to be
Richard> recommended practice is a drastic thing to do.
Richard> I can consider it, if you give me a clear and self-contained
Richard> explanation of what practice you think should be made
Richard> invalid. By self-contained I mean complete in itself,
Richard> designed to be understood without reference to previous
Richard> messages. If you want to refer to anything in the GNU coding
Richard> standards, please quote the passage.
Let me take the example of a2ps. a2ps uses a configuration file which
is installed in syscondir. To find it the path is hard coded in a2ps,
and a natural means to do that would be
AC_DEFINE_UNQUOTED([A2PS_CONFIG_FILE], ["$sysconfdir/a2ps.cfg"])
But this is wrong in two related ways. First it is wrong according to
the standards that allow the user to
./configure
make sysconfdir=/etc
make install sysconfdir=/etc
here, a2ps would look for its file in /usr/local/etc instead of /etc.
Second, because sysconfdir depends upon prefix, what will actually
happen is
#define A2PS_CONFIG_FILE "${prefix}/etc/a2ps.cfg"
There are many people who complain about this: they would like to have
it work properly and immediately have this in config.h:
#define A2PS_CONFIG_FILE "/usr/local/etc/a2ps.cfg"
Autoconf provides no solution for this, since it goes against the
standards, nevertheless there is a macro floating around which makes
this possible: it is soooo simpler! But then of course you face the
failure I described above if you happen to run
./configure
make sysconfdir=/etc
make install sysconfdir=/etc
We are asking for the removal of this feature (i.e., that the sequence
above is considered right). It is bad because 1. it is lying to
configure (and you should never do that!), and 2. I can't imagine any
reason to do that instead of
./configure --sysconfdir=/etc
make
make install
There Should Not Be Several Ways To Do It. (In particular when one is
simple, and the other is only complications.)
Note that this is somewhat independent from another requirement of the
GNU coding standards: supporting
./configure
make
make install prefix=/usr
which does not prevent using the value of the directory variables in
config.h. BTW, I should emphasize that this is not only related to
config.h. Say you are installing shell scripts which need to call
each other. Then, while the natural solution is to list them in
AC_OUTPUT so that config.status performs the right substitution
automagically, you must not do this if you conform to the standards:
you have to simulate config.status by hand with a special make target!
(I append below a part of the Autoconf documentation which tells
people how to support this. I'd like to get rid of it, of course: it
is abnormal to have to tell people how to do something right when the
obvious answer (AC_OUTPUT) is wrong).
----------------------------------------
Now for something different. Personally, I'm not happy with
./configure
make
make install prefix=/usr
either. I'm not asking for its removal, but I confess I don't
understand well why it survived to DESTDIR, which seems to be exactly
what we need.
Why would I consider sane to deprecate this?
1. First because it means the directory variables must exist in two
different forms. If the user runs
./configure --prefix=/usr
then bindir must remain being `${prefix}/bin' in the Makefile (so that
`make install prefix=/usr' still works properly), but in config.h and
everywhere else it must be expanded as `/usr/bin'. This is easy to
address, $bindir and $bindir_expanded, but it is still a complication
for the user.
2. It does not always work right (and I confess that I'm not found of
features you can't depend upon). For instance
./configure --bindir=/bin
make
make install prefix=/usr
will not install the binaries in /usr/bin, but in /bin.
It seems to me that trying to mix `make install' time values with
`configure' hard coded values is not completely right. The only means
to have it right, IMHO, is to have them completely orthogonal. And
DESTDIR is precisely that. DESTDIR has no meaning for configure and
of course should never have. For instance it frightens me to read
`prefix should default to DESTDIR'. To me it is the same as adding
meters to kilograms.
Nevertheless, I agree some people still seem to depend on the ability
to set prefix at `make install', so I am not recommending for its
removal. I'm just questioning the usefulness of this features, and
its soundness. IMHO it was a brilliant idea at the beginning, but
proved to be limited. DESTDIR is the right answer, this is why I be
happy to deprecate the previous attempt.
Akim
PS/ The documentation I wrote to assist people supporting this part
of the standards:
| Installation Directory Variables
| --------------------------------
|
| The following variables specify the directories where the package
| will be installed, see *Note Variables for Installation Directories:
| (standards)Directory Variables, for more information. See the end of
| this section for details on when and how to use these variables.
|
| [........]
|
| Most of these variables have values that rely on `prefix' or
| `exec_prefix'. It is on purpose 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 to her late desires.
|
| `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'.
|
| A corollary is that you should not use these variables but in
| Makefiles. For instance instead of trying to resolve the dependencies
| of `datadir' upon `prefix' and using `AC_DEFINE_UNQUOTED(DATADIR,
| "$datadir")', you should add `-DDATADIR="$(datadir)"' to your `CFLAGS'.
|
| Similarly you should not rely on `AC_OUTPUT_FILES' to replace
| `datadir' and friends in your shell scripts and other files, rather let
| `make' manage their replacement. For instance Autoconf ships templates
| of its shell scripts ending with `.sh', and uses this Makefile snippet:
|
| .sh:
| rm -f $@ $@.tmp
| sed 's,@datadir\@,$(pkgdatadir),g' $< >$@.tmp
| chmod +x $@.tmp
| mv $@.tmp $@
|
| Three things are noteworthy:
|
| `@datadir\@'
| The backslash prevents `configure' from replacing `@datadir@' in
| the sed expression itself.
|
| `$(pkgdatadir)'
| Don't use `@pkgdatadir@'! Use the matching makefile variable
| instead.
|
| `,'
| Don't use `/' in the sed expression(s) since most probably the
| variables you use, such as `$(pkgdatadir)', will contain some.
