[Top][All Lists]

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

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

From: Bruno Haible
Subject: Re: help in deciphering a gnulib-tool/bootstrap issue
Date: Thu, 5 May 2011 16:12:16 +0200
User-agent: KMail/1.9.9

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
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.


  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

    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

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
        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 @@
-  if test $HAVE_MBRTOWC = 0 || test $REPLACE_MBRTOWC = 1; then
-    AC_LIBOBJ([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 @@
+if test $HAVE_MBRTOWC = 0 || test $REPLACE_MBRTOWC = 1; then
+  AC_LIBOBJ([mbrtowc])

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.

In memoriam Peter van Pels <http://en.wikipedia.org/wiki/Peter_van_Pels>

reply via email to

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