Re: Forbidden strings

[Akim Demaille]

>>>>> "Pavel" == Pavel Roskin <address@hidden> 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.