autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Autoconf] Re: HTML format documentation


From: Richard Stallman
Subject: [Autoconf] Re: HTML format documentation
Date: Thu, 14 Sep 2000 03:27:03 -0600 (MDT)

    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.

I think you are right--if we use options, the option name should not have
to be the same as the variable name.

      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.

    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).

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.

    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.

    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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]