same variable name for different headers / Re: AC_CHECK_HEADERS oddity

[Guido Draheim]

Clinton Roy wrote:
> Hey folks,
>
> I'm looking for an ndbm header file, Solaris has <ndbm.h>, Redhat uses
> <gdbm/ndbm.h> and Debian has <gdbm-ndbm.h>, so the call to
> AC_CHECK_HEADERS is:
>
> AC_CHECK_HEADERS(ndbm.h gdbm/ndbm.h gdbm-ndbm.h)
>
> However, the generated configure script seems to think gdbm/ndbm.h and
> gdbm-ndbm.h are the same:
>
> checking ndbm.h usability... no
> checking ndbm.h presence... no
> checking for ndbm.h... no
> checking gdbm/ndbm.h usability... no
> checking gdbm/ndbm.h presence... no
> checking for gdbm/ndbm.h... no
> checking for gdbm-ndbm.h... (cached) no
>
> Is there anything I'm missing?

wwwoooowww, cunning. Quick answer: your way of using the macro is quite
right but autoconf can not handle this kind of thing. And probably it
can not do that (ever) so you have to start using some kind of workaround.

background:
The result of each test is memorized in a "cache". Since we are in plain
shell that "cache" is not an object or special container or something,
it fact the term is rather virtual, and such an object does not exist.
Instead, autoconf will flatten the test strings gdbm/ndbm.h and
gdbm-ndbm.h to a symbol that can be used as a shell variable, and also
prepend a prefix that say "this is a cache variable". In effect, we see:

 ------- test call --------            ------ cache variable used ------
AC_CHECK_HEADER(ndbm.h)                ac_cv_header_ndbm_h=${result}
AC_CHECK_HEADER(gdbm/ndbm.h)           ac_cv_header_gdbm_ndbm_h=${result}
AC_CHECK_HEADER(gdbm-ndbm.h)           ac_cv_header_gdbm_ndbm_h=${result}

see? and if you put these out to a config.h.in it would be

/* Define to 1 if you have the <ndbm.h> header file */
#undef HAVE_NDBM_H

/* Define to 1 if you have the <gdbm/ndbm.h> header file */
#undef HAVE_GDBM_NDBM_H

/* Define to 1 if you have the <gdbm-ndbm.h> header file */
#undef HAVE_GDBM_NDBM_H

see? You can not make use of that in your programs simply because all
the test strings do need to be changed over into a symbol - both
for usage inside the `configure` script itself and for usage inside
your program sources via `config.h`

Solutions?
Before starting out an anything, send a message to the redhat and
debian maintainers of that package and inform them of the situation.
I repeat, send a message - autoconf testing is very very important
for gnuish software, so they _will_ listen. And if they don't,
come back and we'll get out the big guns - this situation is not
acceptable, stop.

If you want to start hacking now, you have to deploy a nasty
workaround. Check the definition of AC_CHECK_HEADER (without
the final "S"). It has an ACTION-IF-FOUND and ACTION-IF-NOT-FOUND
part. Therefore,

AC_CACHE_CHECK(for redhat gdbm/ndbm.h,ac_cv_header_redhat_gdbm_ndbm_h,[
unset ac_cv_header_gdbm_ndbm_h
AC_CHECK_HEADER(gdbm/ndbm.h,
ac_cv_header_redhat_gdbm_ndbm_h="$ac_cv_header_gdbm_ndbm_h"
AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_REDHAT_GDBM_NDBM_H 1)) ])

AC_CACHE_CHECK(for debian gdbm-ndbm.h,ac_cv_header_debian_gdbm_ndbm_h,[
unset ac_cv_header_gdbm_ndbm_h
AC_CHECK_HEADER(gdbm-ndbm.h,
ac_cv_header_debian_gdbm_ndbm_h="$ac_cv_header_gdbm_ndbm_h"
AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_DEBIAN_GDBM_NDBM_H 1)) ])

warning: the code above is not tested, I've just written it up
from memory. It is a demonstration how such an ugly hack would
be done. Again, contact the debian and redhat maintainers, and
tell them. This mail is more for giving you a chance to refer
them to a point explaining the technical heart of the problem.
(or otherwise we would need to memorize this ugly mess in its
 own ac-macro and ship it around - and I do _not_ want that)

good luck,
-- guido                                  http://AC-Archive.sf.net
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-