Re: [Autoconf] Re: HTML format documentation

[Akim Demaille]

>>>>> "Richard" == Richard Stallman <address@hidden> writes:

> XEmacs already uses --with-cc and --with-cflags, although I'd tend
> to go for the shorter --cc=sun-cc and --cflags=-O2.  You'd also need
> --cxx and --cxx-flags; I'm not sure what other environment variables
> are similarly special.

Richard> If we go in that direction, should we say that ALL the
Richard> standard Make variables should have configure options?

No, any variable, *any* variable.  This is under the control of the
user, and if we limit his control by our choices, then she will have
to look at the list of the variables we ``admit'' to decide if she has
to put after before or after `./configure'.  The result will be just
the same as with `./configure; make prefix=/foo': since the result is
unpredictable, and since there is a universal means to obtain the
result I am looking for in a simple way, I will use this natural way'.

In the present case, it just means she will run

CC=my-cc CFLAGS=--emulate-gcc ./configure

and will break her build directory the next time configure is run.




We need no rule here because we address an issue which has no rule:
passing envvars.  We must not try to control anything.  It is also up
to the user to avoid killing herself with

        ./configure AWK=gcc

or other stupid things.  We need no control, more precisely, the users
need no control from a decision made years ago in total ignorance of
her current needs.  They are grown up.  They want control, and
simplicity.  They want to reuse existing interfaces.  They need a
short documentation, not a --help which lists the comprehensive set of
the variables which might affect their configuration, because it means
they have to *check* before running something.

All the configures must run the same way.  Which implies they must all
accept the same set of variables.  An obvious corollary is that either
you accept all the variables, or you will reject one which will be
needed by someone.