Re: ‘libunistring’ module errors

[Bruno Haible]

[ dropping bug-gnulib ]

Hi Ralf,

> I'm fairly sure aclocal does this out of
> necessity, i.e., it might lead to disaster if it were to trace an
> unknown, possibly conflicting set of macro files.  (The other
> possibility why it was done this way is efficiency.)

Yes, I agree. I wouldn't change that.

> I'm actually not sure whether it was an unintended error to let
> aclocal also match words only ending in the above, such as
>   gl_iconv_AC_DEFUN

It probably was not intended, but it was the only workaround I could
find.

> another way to get around that would be, I think,
> 
>   m4_version_prereq([2.64],
>     [m4_pushdef([AC_DEFUN], m4_defn([AC_DEFUN_ONCE]))])
>   AC_DEFUN([AM_ICONV], ...)
>   m4_popdef([AC_DEFUN])

This is extremely risky. It could go into an endless recursion
(in case AC_DEFUN_ONCE is implemented using AC_DEFUN). It could also
possibly not fix the problem (depends on how --trace is implemented).

Possibly I could have used

  AC_DEFUN([gl_LIBUNISTRING], [])
  m4_undefine([gl_LIBUNISTRING])
  m4_version_prereq([2.64],[AC_DEFUN_ONCE],[AC_DEFUN])([gl_LIBUNISTRING], ...)

but this also smells like having unintended consequences.

> The macros which are essentially grepped are AC_DEFUN, AU_DEFUN,
> AC_DEFUN_ONCE, AU_ALIAS

I think more extensibility is needed here. Each of these 4 macros
has side effects that are possibly unwanted. AU_DEFUN and AU_ALIAS
have effects on 'autoupdate'. It would be better - more flexible,
leaving more room for workarounds in unforeseen situations - to
introduce a new macro AC_DEFUN_NOOP:

 -- Macro: AC_DEFUN_NOOP (MACRO-NAME)
     Declare that the macro MACRO-NAME is defined in this file.  It is
     the user's responsibility to actually provide a definition of
     MACRO-NAME as a macro.  The `AC_DEFUN_NOOP' invocation informs
     the `aclocal' program, so that it includes this file when a
     definition of MACRO-NAME is required.

The expansion of this macro would be empty.

Bruno