Re: AC_REQUIRE problems

[Dan Manthey]

On Fri, 18 Feb 2005, Stepan Kasal wrote:

> when I was thinking about the issue, I imagined several #include's in one 
> file,
> to detect the presence of headers.
> We both come to the same conclusion: we can speed up the common case when all
> headers are present, but we cannot get several independent bits of info.
> Even if we were able to parse the error messages, there are still other
> problems:
> 1) what if a broken header screws the preprocessor, eg. with an unmatched
>   #if?  (Similarily for error recovery in the compiler.)
> 2) what about header conflicts?
> 3) What if the compiler stops after 10 errors?
        Yeah, all of those are major problems.  Using multiple translation
units fixes (1), but probably not (3), and (2) pretty much requires that
tests be serial.  I think the only case that can be relied upon is that of
all tests succeeding, which significantly reduces the benefits.

> I also think that the m4 code, which would be gathering the things to test
> for, could be too complicated.
        I've looked into that a bit.  Yes, it's ugly.

> That test would be run near the beginning of the script.
> We can also implement certain algorithm to decide whether we should include
> the test (eg. if at least five of the features there were used in the whole
> configure script).
        It seems that getting AC_REQUIRE, etc to notice such things would
be terribly arcane.  It might be reasonable to just let the user decide
whether to use the aggregate macros.

        With respect to aggregate tests, I have a question of style:  I
have a test like this:

AC_MSG_CHECKING([for a type like uint_fast32_t])
AC_CACHE_VAL(...
  AC_CHECK_TYPE([uint_least32_t],
    AC_COMPILE_IFELSE(...) # check if uint_least32_t is at least an int.
  )
  ...)
AC_MSG_RESULT([found])

In this form, I get the output

checking for a type like uint_fast32_t... checking for uint_least32_t... found
found

I decided on this, but I don't like it:

AC_MSG_CHECKING([for a type like uint_fast32_t])
AC_CACHE_VAL([ac_cv_...],
[AC_MSG_RESULT([(This may take a while.)])
... # all my tests.
AC_MSG_CHECKING([finished for a type like uint_fast32_t])])
AC_MSG_RESULT([found])

This yields

checking for a type like uint_fast32_t... (This may take a while.)
checking for blah...
...
checking finished for a type like uint_fast32_t... found

or, if the value is cached

checking for a type like uint_fast32_t... (cached) found

Is there some standard solution to this ugliness?  (And does this question
suggest that I should rename this thread now?)

-Dan