| CC=sun4-cc ./configure
| Hence, next time configure is run, it forgets about the CC which was
| used to build config.cache, and you get an inconsistent system.
|
| So configure needs the user to tell things instead of doing stuff in
| its back. Hence
|
| ./configure CC=sun-cc
|
| We need to ask: should we do this with VAR=VALUE, or should we use
| --OPTION=VALUE for consistency? Is there a reason to make things like
| the compiler different from other things you can specify at configure
| time?
This is not only related to the compiler, this is related to *all* the
decisions that configure may make. It is about CXX, CXXCPP, M4, AWK,
PERL, YACC, CFLAGS, CPPFLAGS etc.
Hence, we need an open scheme, so I think --VAR=VAL is wrong, there is
way too much risks to confuse actual options with variables, or to
forbid any extension in the future. So maybe something like
--set-CFLAGS=-ggdb?
But why ask for more things to type? In addition, why invent another
interface than the one everybody knows: that of make. It is of prime
importance that existing (good) interfaces be reused, and in addition
since there is a tight relationship between make and configure, I
consider it's of prime importance to keep the VAR=VAL syntax.
Also, I consider it a bug from a program not to report all the options
it supports in its --help. Here, with --set-VAR=VAL it is just
impossible to. You will never have a list of all the variables that
influence the results of configure.
| Can anyone suggest a systematic criterion for deciding which data to
| specify with options, and which with variables?
Options are used to change the deep behavior of configure, while
variables are here just as if they were envvars: they correspond to
defaults the user has chosen. Variables are also meant for the
Makefile. This is why I also suggested
./configure bindir=/bin
make
which is to parallel with the compliant
./configure
make bindir=/bin
This is also why Alexandre suggested to extend this to prefix too:
Broken:
./configure
make prefix=$HOME
Good:
./configure prefix=$HOME
make
We must not make it more complex to use configure, it's quite the
opposite: people want more predictability, more simplicity, more
natural behaviors. VAR=VAL is the right answer.
Alternatively, just imagine configure was a C program. You'd *never*
imagine using such a scheme (--set-VAR=VAL). Maybe something like -D
in compilers and m4, but not --set-VAR=VAL. But configure does not
need such an option, there is no ambiguity over the meaning of
`VAR=VAL', and all configure wants is being like its buddy make.
