Hello Ralf,
> What does it need to persuade you to move to recommend
> ./configure CC=cc [...]
>
> instead of the other way round? Autoconf (and Automake)
> mailing lists still get bug reports which are due to
> ./config.status --recheck
>
> forgetting the settings, which is due to people still
> using (and reading about) the old way of setting CC etc.
Hmm, there are four reasons why I still recommend to use configure
with environment variables:
1) For the user, especially when building several packages, or needing
several attempts until one succeeds, it's simpler to set an environment
variable once for the entire session, than to remember to set not
only --prefix, but all the other stuff, at every configure invocation.
2) As a user, when I build packages in several directories in parallel
in multiple xterms, it's easier to do
$ echo $CC
to view the current settings, than to grovel 200 lines across config.status
in order to see the settings. This is a thing that autoconf could do
better: show in a comment, very near the beginning of config.status,
the settings that were used. Not hidden after 200 lines.
3) A recommendation to use VAR=value in the configure command line will
not work with some 'configure' scripts that comply to GNU standards
but are not generated by autoconf. For example, GNU clisp's toplevel
configure script is written by hand and does not support VAR=value.
In other words, if you want to make universal recommendations, they
should IMO be based on the GNU standards.
4) If "./configure CC=cc" is supported, people may easily think the
same holds for "make". Such as "make CC=cc" or
"make install prefix=/opt/gnu". But these are unsupported (the
first one because so many details about $CC are extracted into
config.h, the second one because paths to message catalogs etc.
are hardcoded into the built executables).
Bruno
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
