Why the misleading message? (was Re: present but cannot be compiled)

[Dan Hoey]

On 18 Dec 2003, Akim Demaille wrote:

[ > On 25 Nov 2003, Frederic L. W. Meunier wrote: ]

> > On Mon, 17 Nov 2003, Akim Demaille wrote:
> >> Thanks for the bug report!
> >> 
> >> Contrary to the message reported by ./configure, this is not a bug in
> >> Autoconf, but the result of a recent incompatible change in Autoconf
> >> that is likely to require the package's configure.ac to be updated.
> >> Please, first make sure you are trying the most recent version of that
> >> package, then, if you are, send all this message (including your
> >> output attached) to the bug list (or the authors) of the package you
> >> were trying to configure.

> > Why does Autoconf ask people to report it to bug-autoconf ?
> > What about changing the misleading message if it hasn't already
> > been done ?

> This is the simple result of propagation: you used a script generated
> before the change was made.

I don't know what you mean by "generated" or "the change".  I found
this (in the developmental gnu emacs distribution) because someone
inserted AC_CHECK_HEADERS(net/if.h) into configure.ac and ran autoconf
2.57; I presume it worked on their system, but on MacOS X (built on
darwin) you need at least sys/types.h and sys/socket.h before
net/if.h.

As far as I can see, it was autoconf that produced the message about
contacting bug-autoconf, and that is claimed to be erroneous (and has
the unfortunate side-effect of provoking yet another copy of those
instructions that almost seem to explain the situation.  At this point
Google finds thousands of such posts in various versions).

At any rate, if AC_CHECK_HEADERS(random system-dependent-headers)
finds problems that bug-autoconf would handle with a form letter, the
message should include a URL where we can find the form letter, and
maybe even _the current version of the form letter_.  If that's what
2.59 does, it's great; if not, please consider it for the next
release.

By the way, you might want to clean up the code in present-doc.h that
has double brackets (if, as I think I read in some info file, double
brackets are now deprecated).

In fact, the piece of code
          #include <stdio.h>
          #if STDC_HEADERS
          # include <stdlib.h>
          # include <stddef.h>
          #else
          # if HAVE_STDLIB_H
          #  include <stdlib.h>
          # endif
          #endif
          #if HAVE_SYS_SOCKET_H
          # include <sys/socket.h>
          #endif
that present-doc.txt tells us to pass to AC_CHECK_HEADERS(if.h,...) is
getting a little long, especially since it also needs to be passed to
AC_CHECK_MEMBERS for testing the members of the structures that if.h
defines.  Also, I'm not sure if that solves the problem of including
sys/types.h, which is the solution I came up with.

Perhaps in the future feature list we could have

 - Macro: AC_CHECK_HEADERS (HEADER-FILE..., [ACTION-IF-FOUND],
              [ACTION-IF-NOT-FOUND], [INCLUDES = `default-includes'
              IFINCLUDES = 'conditional-includes'
              other-required-code
          ] )

which would expand into

    AC_CHECK_HEADERS (conditional-includes)
    AC_CHECK_HEADERS (HEADER-FILE..., [ACTION-IF-FOUND],
          [ACTION-IF-NOT-FOUND], [
#include <include-file.h>    (for "include-file.h" in default-includes)

#ifdef HAVE_IFINCLUDE_FILE_H  (for "ifinclude-file.h"
#include ifinclude-file.h        in
#endif                             conditional-includes)

other-required-code
] )

with possibly some special dispensations for things like stddef.h.
Note that if the conditional-includes themselves require
conditional-includes, we need to precede this with explicit
AC_CHECK_HEADERS so that the HAVE_IFINCLUDE_FILE_H symbols get
cached.

Then we would end up with

    AC_CHECK_HEADERS(sys/socket.h,,,[IFINCLUDES='stdlib.h stddef.h
            sys/types.h'])
    AC_CHECK_HEADERS(sys/if.h,,,[IFINCLUDES='stdlib.h stddef.h
            sys/types.h sys/socket.h' ])
    AC_CHECK_MEMBERS([struct ifreq.ifr_flags],[IFINCLUDES='stdlib.h
            stddef.h sys/types.h sys/socket.h sys/if.h' ])

Of course, it would be nicer if we could somehow get autoconf to
remember (from the previous AC_CHECK_HEADERS) just what headers
each include file requires, so we could have

    AC_CHECK_HEADERS(sys/socket.h,,,[IFINCLUDES='stdlib.h stddef.h
            sys/types.h'])
    AC_CHECK_HEADERS(sys/if.h,,,[IFINCLUDES='sys/socket.h' ])
    AC_CHECK_MEMBERS([struct ifreq.ifr_flags],[IFINCLUDES='sys/if.h' ])

Anyway, I hope this helps improve the future utility of autoconf.  It
could be that my proposed approach is somehow antithetical to the
whole reason that the "present but cannot be compiled" issue was
invented--I'm not a portability expert.  I just want to be able to
compile the software.

Sincerely,
Dan Hoey

address@hidden

Hoey"at"AIC.NRL.Navy.Mil (I hope this escapes being bogus-exemplified.
    I don't keep my e-mail address a secret.  That doesn't constitute
    permission to spammers, nor did it ever.  Spam is when you say the
    same thing lots of times.  Charitable solicitations, noncommercial
    drivel, IPO offers, even monetary donations are spam if sent in
    bulk to people who didn't ask for them.  TAKE BACK THE INTERNET!
    This has been an unpaid and somewhat irrelevant rant incidental to
    a substantive and relevant post.  Please respond to the rant only
    where relevant.  Toner is not a food. )