Re: autoconf generates buggy configure

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Akim Demaille wrote:

> |    1) text from inside an AC_HELP_STRING() macro was NOT placed in the
> |    help section.  Instead, it was just willy-nilly put into the script
> |    itself.  Since help text is not, in general, valid shell script,
> |    this caused errors.  Other AC_HELP_STRING()'s behaved as expected.
> 
> This macro should never have existed, as it is quite not writable with
> the current GNU M4.  Just don't use [ ] in it.  That's its problem
> #1.  Yes, it is a bug, we do agree.  We just don't have the technology
> to write one good implementation of it.  So, please, don't use it when
> [ and ] are needed.  Use AC_ARG_ENABLE etc. with a literal as documentation.


Okay.  Here I thought I was doing it "right" -- since the docu 
recommends using AC_HELP_STRING()...

So, you're saying that BOTH the following are okay?

AC_ARG_ENABLE([client],
AC_HELP_STRING(--enable-client,
   include code for running as a remote client (default)),
<stuff if given>,
<stuff if not given>)

and (ignore bogus linewrap)

AC_ARG_ENABLE([client],
[  --enable-client         include code for running as a remote client 
(default)],
<stuff if given>,
<stuff if not given>)


> 
> |    2) case statements were completely hosed (no closing ')' on the
> |    match strings, a random 'fi' just dropped in between the match
> |    string and the execution clause, ...
> | 
> | 
> |    3) if statements not closed: 'fi' or 'else' ommitted...
> 
> All these are typical of ``user-error or a buggy-configure.in'' :)


Glad to hear it.  I'd much rather the problem be with my usage than with 
configure itself.  (easier to fix...)


> Just make sure you strictly follow the quotation rules (see the
> documentation).  If you don't, then, because of the silly Bourne Shell
> syntax (I mean, I find the syntax itself silly, I'm not having an
> Autoconf bias here) which has unbalanced `)', M4 will think your
> case's `)' are macro invocation closers.
> 
> | Again, this is true for ac-2.53, ac-2.53a, and ac-2.52. 
> 
> Sure!  A broken configure.in is broken independently of the Autoconf
> version :)
> 
> | --- cvs-1.11.2-orig/configure    2002-05-19 06:46:53.000000000 -0400
> | +++ cvs-1.11.2/configure    2002-05-19 06:16:46.000000000 -0400
> | @@ -848,6 +848,8 @@
> |     --disable-dependency-tracking Speeds up one-time builds
> |     --enable-dependency-tracking  Do not reject slow dependency extractors
> |     --enable-encryption     enable encryption support
> | +  --enable-client         include code for running as a remote client
> | +                          (default)
> 
> Post your AC_ARG_ENABLE invocation for `client' please.


Okay, but it's identical to the AC_ARG_ENABLE invocation for server, 
which works...(the second argument to AC_HELP_STRING is wrapped by my 
mailer, but not in the orginal code).

AC_DEFUN([ENABLE_CLIENT],[
   AC_ARG_ENABLE([client],
     AC_HELP_STRING([--enable-client],
                    [include code for running as a remote client 
(default)]),
     [case "${enableval}" in
       yes) client=yes;;
       no) client=no;;
       *) AC_MSG_ERROR([bad value ${enableval} for client option]) ;;
     esac],
     [if test "x$ac_cv_search_connect" != "xno"; then
       client=yes
     fi])
   if test x$client = xyes; then
     AC_DEFINE([CLIENT_SUPPORT],1,
       [Define if you want CVS to be able to be a remote repository
       client.])
   fi
])


> | @@ -6037,6 +6039,7 @@
> |   #define HAVE_GETSPNAM 1
> |   _ACEOF
> | 
> | +fi
> 
> Post your invocation which check for getspnam.  I bet you embed an
> AC_DEFINE which is not quoted.  Read the documentation, it is fairly
> explicit about this issue.


AC_SEARCH_LIBS(getspnam, sec gen,
   AC_DEFINE([HAVE_GETSPNAM],1,
   [Define if you have the getspnam function.])


> | @@ -6307,9 +6310,7 @@
> | 
> |   # So?  What about this header?
> |   case $ac_header_compiler:$ac_header_preproc in
> | -  yes:no
> | -fi
> | -
> | +  yes:no )
> 
> Post your code, and see yourself that it includes a macro invocation
> which is not quoted.


The preceeding code sample is from the section of configure generated by:

AC_CHECK_FUNC(gethostname, :, AC_LIBOBJ([hostname])

 
> | @@ -9566,13 +9561,12 @@
> |   echo "$as_me: error: cannot find gdbm.h" >&2;}
> |      { (exit 1); exit 1; }; }
> |   fi
> | -
> | -,
> 
> This comma is another side effect of the underquotation: it was meant
> to separate a macro's arguments, but before this comma, there is case
> stmt that fooled M4.


The preeceeding code sample is from the secion of configure generated by 
  the macro below (there's another bogus mailer induced linewrap, below):

AC_DEFUN([WITH_GDBM],[
   AC_ARG_WITH([gdbm],
     AC_HELP_STRING([--with-gdbm],
                    [use gdbm for database access]),
     [ac_cv_use_gdbm=$withval], [ac_cv_use_gdbm=no])
   AC_CACHE_CHECK([whether to use gdbm],
                  [ac_cv_use_gdbm], [ac_cv_use_gdbm=no])
   if test x$ac_cv_use_gdbm = xyes; then
     AC_DEFINE([USE_GDBM],1,
       [Define if you wish to use a gdbm database for modules and val-tags])
     LIBS="$LIBS -lgdbm"
   fi
   dnl Now check for libgdbm and gdbm.h
   if test x$ac_cv_use_gdbm = xyes; then
     AC_CHECK_LIB(gdbm, gdbm_open,
       AC_CHECK_HEADER(gdbm.h,
         AC_DEFINE([HAVE_GDBM],1,
           [Define if you have the gdbm library and headers]),
         AC_MSG_ERROR([cannot find gdbm.h])),
       AC_MSG_ERROR([cannot find libgdbm]))
   fi
])

I'm overjoyed that the problem is me.  However, I don't understand what 
it is that I did wrong.  I tried to '['/']' quote everything I could, 
just to be safe (the autoconf manual says "When in doubt, quote"). Is 
there a good M4 programming manual that could instruct me on this?

--Chuck