[Autoconf] Re: HTML format documentation

[Akim Demaille]

|       So maybe something like
|     --set-CFLAGS=-ggdb?
| 
| That is a uniform scheme but not very convenient.  Since all of these
| options would be designated by us, and we would make an explicit list
| of them, we don't have to limit ourselves to a simple uniform naming
| scheme.

Please, do take simplicity of implementation, documentation and
learning into account.  A scheme that needs details explanation is
necessarily wrong for all of us.  configure should remain simple, it's
documentation must remain easily understood, and exceptions must
avoided at any cost.


|     But why ask for more things to type?
| 
| The issue is whether to keep the configure interface consistent (all
| data is specified by options) or have two different ways to do it
| (some data by options, some by variables).

I agree, and this is why I proposed to move the foodir into the domain
of variables too.  But certainly not --with and --enable etc. because
these are truly options.

In fact, I'm fine with --foodir (I do not like --dir-foo at all
because again it introduces additional complications for the users:
they have to face two names: the ones used by configure, and the ones
used by make), because they are very specific to configure.

But in the case of CC, CFLAGS etc. these guys are traditional envvars,
they have deeply a nature of variables.  This is why I think VAR=VAL
is just perfect: it's a well know syntax, known by everybody, and in
addition, it is the same as that of make(1).



| And if we have two different ways, how do we decide which data to
| specify with options and which with variables?  I see no clean way.
| It is a very unsatisfactory solution.

It seems to me very simple to me: all the variables which are likely
to be envvar, or, variables that can be passed to make.  There is just
no question for most variables (AWK, TAR, YACC, POSIXLY_CORRECT etc.),
I agree the only ambiguity that remains is the case of the foodir
variables.

I'm fine with keeping --foodir.
I'm sad you decided to add --dir-foo.

But these variables should not limit ourselves in the sake of
simplifying configure's uses while making it more robust.


|     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.
| 
| It is just as bad to have a variable which affects configure and is
| not mentioned, as to have an option which affects configure and is not
| mentioned.

Personally, I think it is different.  I agree important variables must
be documented, and they already are.  But remember that these
variables are also envvars, and they are system wide!  There is no
reason for configure to document system wide variables.

If the user wants to pass POSIXLY_CORRECT, let him do so.  But I see
no point in having configure document it.

If the user must pass special flags for his sed to give better results
in configure, let him pass his options to configure, that's important.

Who knows what variable will affect what?  Neither the Autoconf
maintainers nor the configure.in maintainer.  That's only a concern
for the installer, the terminal user.   If ever we settle a counter
intuitive interface, with some sort of control which reduces the
feature to an unsatisfying subset, the result will be that people will
run

        MY_PRECIOUS_ENNVAR_FOR_CONFIGURE=precious-value ./configure

and we will have lost all our work which aim was simply to have
configure be aware of the special values the users put in their
envvars when they run configure.


|     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.
| 
| Having two different kinds of syntax for the same kind of thing
| is both less predictable and less simple than having one kind of syntax.

ROTFLOL!

Seriously, reading such a sentence from you after the debate over the
much more grave problem of

1.
   ./configure --prefix=/foo                ./configure
   make                            VS       make prefix=/foo

2.
   --host, --build, and --target   VS   TRIPLET

makes me wonder what exactly you consider a problem.


The two problems above are actual problems because they raise deep
semantic problems, and real ambiguity in addition to complication of
the implementation (for the users of Autoconf, I'm not talking about
us), while the VAR=VAL issue is a non issue.

If someone write

        ./configure foodir=/foo --foodir=/bar

or

        ./configure --foodir=/foo foodir=/bar

everybody will agree that the last value is right.  And anyway, we
already have zillions of alternative ways to do what I'm referring to:
via ~/.env, via env(1), or on the cmd line before ./configure, or via
config.site, etc.

We are talking about something which is as plain stupid as

        assigning a value to a variable

really, I can't understand the point of this debate.