Hi Eric,
> if gl_PREREQ_whatever is changed to have no output (as you just did
> here, by changing : to AC_REQUIRE), then you created a syntax error.
Oops, you're right. I propose to use the patch below instead.
> In general, I've been starting to steer away from trivial gl_PREREQ blocks
> (those with only : or AC_REQUIRE). If I understand correctly, they were
> originally developed to help minimize redundancy and avoid expand-before-use
> problems in configure.ac
Not really. The purpose of the idiom of separating the gl_PREREQ_FOO macro from
the gl_FUNC_FOO macro is merely to ease maintenance:
- Each time you change the contents of the foo.h or foo.c files, you are
supposed to update the foo.m4 file accordingly. For example, when you drop
the use of 'inline', remove the invocation of AC_C_INLINE. This is much
easier done when the prerequisites of foo.h and foo.c are separated.
- Sometimes, an invocation like AC_USE_SYSTEM_EXTENSIONS is necessary for the
gl_FUNC_FOO part, sometimes for the gl_PREREQ_FOO part. With the usual
habit to hoist all AC_REQUIREs at the beginning, you cannot distinguish
these two cases if gl_PREREQ_FOO is not a separate macro. But you need to
know it when, for example, you write other autoconf tests which use the
function foo.
- The foo.m4 files are often complex enough that any reasonable way of
structuring them is welcome.
Bruno
--- m4/chdir-long.m4.orig Thu Dec 31 17:13:02 2009
+++ m4/chdir-long.m4 Thu Dec 31 17:12:51 2009
@@ -1,4 +1,4 @@
-#serial 10
+#serial 11
# Use Gnulib's robust chdir function.
# It can handle arbitrarily long directory names, which means
@@ -34,5 +34,6 @@
AC_DEFUN([gl_PREREQ_CHDIR_LONG],
[
+ AC_REQUIRE([AC_C_INLINE])
:
])
