[ 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