Hello Bruno, * Bruno Haible wrote on Tue, Aug 08, 2006 at 04:32:55PM CEST: > > > What does it need to persuade you to move to recommend > > ./configure CC=cc [...] > > > > instead of the other way round? > > mailing lists still get bug reports which are due to > 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. This strikes me as inconsistent, although I see your point. Personally, I tend to just put the whole configure line in a (one-line) script or a shell variable. Or use shell history. The fact that you have to remember --prefix and some other options anyway is a good reason to treat all of them in the same way. > 2) was addressed by Andreas already. I could note that I proposed a ./config.status --config with output reusable for another configure invocation, a while (about a year, IIRC) ago, but we couldn't easily make it work well with all kinds of corner cases, and I forgot about it afterwards. > 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. OK, if that's what it takes to convince you, that is what we should do (quickly). > 4) If "./configure CC=cc" is supported, people may easily think the > same holds for "make". I don't think that is such a problem in practice. > 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). Both are used widely though, the first to do minor changes, like a quick debugging build with -g added to $CC or $CFLAGS (yes, we all know that this could in principle also alter config.h values, but we are reasonable and prepared to expect that case ;-), and the second is mentioned in the GCS (section 'Directory Variables') as another way to do staged installs, although I like DESTDIR much better and think the other should be banished for the reasons you state. Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
