Re: fix autoreconf when ACLOCAL_AMFLAGS is AC_SUBSTed

[Stepan Kasal]

Hello Alexandre,
  thank you for your prompt answer.

On Fri, Mar 11, 2005 at 08:41:23AM +0100, Alexandre Duret-Lutz wrote:
> 2) [...] I find it inappropriate that autoreconf
>    behave differently whether a package has already been
>    configured or not.

I admit I had a similar feeling.  On a second thought, I agree with you
and I forget about this patch.

Anyway, let me answer your other comments.

> 1) If I change the value of ACLOCAL_AMFLAGS in my Makefile.am
>    and run autoreconf immediately afterwards, this causes
>    autoreconf to use the old value that is still in Makefile.
>    This sounds bogus.

Could be fixed by processing Makefile.am and Makefile, in this order.

> 3) autopoint and libtoolize, i.e., the tools autoreconf runs,
>    look at ACLOCAL_AMFLAGS in Makefile.am.

No doubt they would have to use the same algotrithm as autoreconf.

> 5) The rationale for or explanation of a block of code should be
>    in front of that block of code, not in the ChangeLog.

Sure, my fault.  I'll try to remember this.

> 4) I couldn't find a reason why one want to AC_SUBST([ACLOCAL_AMFLAGS])

OK, let me tell you the story which led to this patch:

I have Gnome installed at /opt/gnome.  This means that Gnome autoconf
macros are in /opt/gnome/share/aclocal and I have to tell this to
aclocal.

There is no env. variable ACLOCAL_PATH, or something like that.
I have just re-read your aclocal documentation and discovered that
I'm supposed to use `dirlist'--I'll do that.

But previously, I used an errorneous solution: I set ACLOCAL_FLAGS,
because gnome-autogen.sh then calls  $ACLOCAL $ACLOCAL_FLAGS

This meant that gnome-autogen.sh gave correct results, but the
regeneration command in Makefile was broken.  That was why I did
        AC_SUBST([ACLOCAL_AMFLAGS], [$ACLOCAL_FLAGS])

I submit ll revert that change in gnumeric and submit a patch to
gnome-autogen.sh which will issue a warning if $ACLOCAL_FLAGS is used.

Thanks,
        Stepan Kasal