>>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Why do we do it? Whe want to protect the user from
Pavel> overquoting. When I was suggesting to protect from underquoting
Pavel> nobody seemed to be enthusiastic about it although it is
Pavel> underquoting that results in truly weird problems.
That's one part of it, the other being misspelled macro names, or
simply undefined macros (think of AM_INIT_AUTOMAKE when aclocal was
not run). As a matter of fact, overquoting is marginal.
Pavel> What the forbidden strings are trying to prevent is invalid
Pavel> "configure". There are better ways to check it. Automake
Pavel> provides the "distcheck" target that ensures that the package
Pavel> can be compiled. This includes running "configure".
That's not enough: there is no guarantee you cover the whole code.
There is just no means to guarantee that a shell script is a legal
shell script. `sh -n' can help to falsify the sentence `this script
is valid', but really has no value whatsoever wrt verifying this
assertion.
Pavel> Another approach is to use "$SHELL -n" to check validity of
Pavel> "configure". Of all shells I have installed on my Linux box
Pavel> only zsh couldn't detect "AC_FOO(bar)" as a syntax error. I
Pavel> believe it's acceptable to ask maintainers to have bash
Pavel> somewhere on the system (I don't even say as /bin/sh or $SHELL)
Pavel> if they want to catch their errors earlier.
This is still not enough. Think of all the heredocs we have in
there. No sh -n will ever catch
/tmp % cat configure.in nostromo 17:32
AC_INIT
AC_COMPILE_IFELSE([AC_LNG_PROGRAM([return 0])],
[exit 0],
[exit 1])
/tmp % ace nostromo 17:32
configure.in:2: error: undefined macro: AC_LNG_PROGRAM
/tmp % sed -n '/_ACEOF/,/_ACEOF/p' configure | tail nostromo Err 1
main ()
{
;
return 0;
}
_ACEOF
cat >conftest.$ac_ext <<_ACEOF
AC_LNG_PROGRAM(return 0)
_ACEOF
The one and only approach is the current one. Let's stop reinventing
the wheel.
Pavel> Another question is the namespace. I agree that Autoconf
Pavel> shouldn't be so greedy. One name per package should be the
Pavel> right way. I.e., AC for autoconf, AM for automake, LT for
Pavel> libtool. It should be easy to rename A[HSTU]_* to something
Pavel> else before 2.50.
I am strictly, ferociously, against this.
Pavel> It will be harder to do it later.
But what's the point???
I don't understand your logic here. Everybody seems to be afraid
because of AR_FLAGS, but frankly, what makes it any different from
AC_FLAGS? Why should we pay attention to *some* characters, and not
for others. This is gross. Only uniformity will save Autoconf from
being a big stack of disordered macros it used to be.
It means that we have to recognize that it is unfair to reserve *any*
strings without giving the means to users to escape this limitation we
impose. But *then*, I see no reason to limit ourselves to AC_.
There are many challenges waiting for Autoconf. Some of them will
require additional families. AY (or whatever) comes to my mind, for
Autosystem, i.e., creating system.h. A year or so ago, I had an
encouraging prototype. I'm happy AS_ is born.
The prefixes *are* important, because macros from AH_ have *nothing*
to do with AC_ macros and so on.
Please, give the maintainers a little of freedom to be at peace.
There's enough to fight with so that we don't need the additional
pressure of using AC_DIRTY_EXTRA_LONG_MACRO_NAME. I worked hard to
have Autoconf sources pleasant to read and maintain and understand,
don't break that.
