[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AC_CACHE_CHECK and complex tests

From: Ralf Wildenhues
Subject: AC_CACHE_CHECK and complex tests
Date: Fri, 24 Feb 2006 20:48:48 +0100
User-agent: Mutt/1.5.9i

Real life Autoconf macros sometimes are too complex to fit their
results in one cache variable.  But they are also too expensive
to be run several times.  Several of these exist and are widely used.

The patch below adds an example of how such a test may be written
properly.  I'm a bit uncertain as to whether it should be applied:
we would constrain Autoconf in a way that we could not possibly know
the names of the other cache variables, by documenting this.

Maybe we should instead require the user to list all cache variables,
even if we don't make use of the other ones now?  This could be done by
making CACHE-ID (the second argument of `AC_CACHE_CHECK') a list (M4
or space-separated?), or, backward-compatibly with older Autoconf
versions, by an additional fourth argument (that way macros written the
new style would work with older Autoconf as well), and it could allow a
future implementation to implement consistency checking and better error


Note also the example given is poor in the sense that it is not very
expensive at all.  Better suggestions much appreciated.

Note the patch also cleans up the style of the previous examples a bit
(and would IMVHO be good to be applied even if the main part is not ok).


        * doc/autoconf.texi (Caching Results): Fix the examples to use a
        recommended quoting style and discard unwanted output.
        Add an example of how complex tests could cache more than one
        value at a time.

Index: doc/autoconf.texi
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.954
diff -u -r1.954 autoconf.texi
--- doc/autoconf.texi   22 Feb 2006 20:18:23 -0000      1.954
+++ doc/autoconf.texi   24 Feb 2006 20:02:02 -0000
@@ -7585,8 +7585,8 @@
 [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
-                 true && ac_cv_shell_true_works=yes
-                 if test $ac_cv_shell_true_works = yes; then
+                 (true) 2>/dev/null && ac_cv_shell_true_works=yes
+                 if test "$ac_cv_shell_true_works" = yes; then
                    AC_DEFINE([TRUE_WORKS], [1],
                              [Define if `true(1)' works properly.])
@@ -7604,8 +7604,8 @@
 [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
-                 true && ac_cv_shell_true_works=yes])
- if test $ac_cv_shell_true_works = yes; then
+                 (true) 2>/dev/null && ac_cv_shell_true_works=yes])
+ if test "$ac_cv_shell_true_works" = yes; then
              [Define if `true(1)' works properly.])
@@ -7619,6 +7619,35 @@
 the results of the check are retrieved from the cache or determined by
 running the shell commands.
+For more complex tests, it may be useful to store and cache more than
+one value per test.  This can be achieved by using several cached
+variables, all of which are associated with the one test (and not used
+by other tests), and making one variable the @var{cache-id}.  Assuming
+a package @samp{foo} comes with a program @code{foo-config} to provide
+flags for its use, one could write something along these lines:
+[AC_CACHE_CHECK([for library flags of the foo package], [ac_cv_foo_libs],
+                [ac_cv_foo_libs=no
+                 ac_cv_foo_cppflags=
+                 (foo-config --help) >/dev/null 2>&1 && @{
+                   ac_cv_foo_libs=`foo-config --libs`
+                   ac_cv_foo_cppflags=`foo-config --cppflags`
+                 @}])
+  if test "$ac_cv_foo_libs" != no; then
+    AC_MSG_CHECKING([for preprocessor flags of the foo package])
+    AC_MSG_RESULT([$ac_cv_foo_cppflags])
+    CPPFLAGS="$CPPFLAGS $ac_cv_foo_cppflags"
+    LIBS="$ac_cv_foo_libs $LIBS"
+  fi
address@hidden example
+Unless the tests are very expensive, it is better to use separate cached
+checks, though; the example above is not good in this regard.
 * Cache Variable Names::        Shell variables used in caches
 * Cache Files::                 Files @command{configure} uses for caching

reply via email to

[Prev in Thread] Current Thread [Next in Thread]