Hi Eric,
> >>> ./bootstrap: aclocal -I m4 --force -I 'gnulib/m4' ...
> >>> missing file gnulib/tests/fseeko.c
> >>> configure.ac:80: error: expected source file, required through
> >>> AC_LIBSOURCES, not found
> ...
> the relaxation of fclose
> dependencies changed fflush from mandatory to test-only, but in the
> process, made it so that gl_REPLACE_FSEEKO is called while servicing the
> wrong directory.
Thanks for the analysis.
> So, one trick is to make the various gl_REPLACE_* functions one-shot -
> once a function has been replaced, then it shouldn't need replacing
> again (where the second call might be an attempt to do a second
> replacement in a test directory).
>
> diff --git i/m4/fseeko.m4 w/m4/fseeko.m4
> index 76507d1..eb5f2f3 100644
> --- i/m4/fseeko.m4
> +++ w/m4/fseeko.m4
> @@ -52,6 +52,9 @@ AC_DEFUN([gl_REPLACE_FSEEKO],
> AC_LIBOBJ([fseeko])
> dnl If we are also using the fseek module, then fseek needs replacing, too.
> m4_ifdef([gl_REPLACE_FSEEK], [gl_REPLACE_FSEEK])
> + dnl Once we have replaced the macro in the libs directory, we don't
> + dnl need to replace it in the tests directory
> + m4_pushdef([gl_REPLACE_FSEEKO])
> ])
This fix is not good, IMO. gnulib-tool already moderately supports multiple
gnulib-tool invocations in the scope of the same configure.ac (with different
--macro-prefix parameters, of course). And we want to support that fully;
Sam and Gary have been pushing for this.
In other words, gl_source_base being assigned "." and then later "tests"
is only a special case. In the run of a single configure,
gl_source_base might take on multiple values
"."
"subdir1"
"subdir2"
When a module has been enabled for subdir1, it does not mean that it can
be dropped from subdir2. The plan is to add a separate --basedir option
to gnulib-tool that identifies the cases where a module can be dropped
because it is already enabled in a particular other directory.
Therefore:
1) The problem here is that fflush.m4 invokes gl_REPLACE_FSEEKO,
which does an AC_LIBOBJ of a file outside module 'fflush'.
2) AC_REQUIRE of a macro that does AC_LIBOBJ is forbidden.
As a template how to fix 1), look at the modules 'mbrtowc' and 'mbrlen':
In mbrlen.m4 we have the code
AC_REQUIRE([gl_FUNC_MBRTOWC])
...
dnl Most bugs affecting the system's mbrtowc function also affect the
dnl mbrlen function. So override mbrlen whenever mbrtowc is overridden.
dnl We could also run the individual tests below; the results would be
dnl the same.
if test $REPLACE_MBRTOWC = 1; then
REPLACE_MBRLEN=1
fi
That is, it's not the 'mbrtowc' module which triggers an AC_LIBOBJ([mbrlen])
but it's the 'mbrlen' module which asks the 'mbrtowc' module whether it
should do AC_LIBOBJ([mbrlen]). A similar thing should be done with 'fflush'
and 'fseeko'.
But now I see that this code is not fully correct either: It does
AC_REQUIRE([gl_FUNC_MBRTOWC]), violating rule 2) above. In fact, it should
do an AC_REQUIRE of the autoconf tests of mbrtowc, _without_ the
AC_LIBOBJ([mbrtowc]) invocation.
This, together with the fact that now the condition under which an
AC_LIBOBJ is done is duplicated in the module description (for the
conditional dependencies), makes me think we should change our idioms
and
move all AC_LIBOBJ invocations to the configure.ac part of the
module description.
In other words:
Distinguish the autoconf tests (that determine some variables)
from the action (AC_LIBOBJ invocations).
The autoconf tests can be AC_REQUIREd, the actions cannot.
Here's an example of what I mean:
--- m4/mbrtowc.m4.orig Thu May 5 16:05:22 2011
+++ m4/mbrtowc.m4 Thu May 5 16:05:09 2011
@@ -53,10 +53,6 @@
esac
fi
fi
- if test $HAVE_MBRTOWC = 0 || test $REPLACE_MBRTOWC = 1; then
- AC_LIBOBJ([mbrtowc])
- gl_PREREQ_MBRTOWC
- fi
])
dnl Test whether mbsinit() and mbrtowc() need to be overridden in a way that
--- modules/mbrtowc.orig Thu May 5 16:05:22 2011
+++ modules/mbrtowc Thu May 5 16:05:05 2011
@@ -20,6 +20,10 @@
configure.ac:
gl_FUNC_MBRTOWC
+if test $HAVE_MBRTOWC = 0 || test $REPLACE_MBRTOWC = 1; then
+ AC_LIBOBJ([mbrtowc])
+ gl_PREREQ_MBRTOWC
+fi
gl_WCHAR_MODULE_INDICATOR([mbrtowc])
Makefile.am:
The benefits of these changed idioms will be:
- It becomes impossible to accidentally AC_REQUIRE an
AC_LIBOBJ invocation.
- The consistency between AC_LIBOBJ invocations and conditional dependencies
is easier to maintain.
- Instead of fflush.m4 invoking gl_REPLACE_FSEEKO, we can have
fseeko.m4 do a AC_REQUIRE([gl_FUNC_FFLUSH]), which solves the bug you found.
Bruno
--
In memoriam Peter van Pels <http://en.wikipedia.org/wiki/Peter_van_Pels>
