Re: help in deciphering a gnulib-tool/bootstrap issue

[Bruno Haible]

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>