Re: Broken makefile given Autoconf version mismatch

[Stepan Kasal]

Hello Alexandre,

On Thu, Apr 20, 2006 at 09:12:01AM +0200, Alexandre Duret-Lutz wrote:
> >>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:
> 
>  adl> Here is my attempt at checking Autoconf version in aclocal.m4.
...
> Here is a second attempt [...]
...
>    * It does not pollute aclocal.m4 with a version check if
>      automake is not used.  (The contents of aclocal.m4 is not
>      really dependent on the Autoconf version, so I see little
>      point in this check if it's not for Automake.)

[Since the thread is getting long, let me repeat a summary of the
original problem: If a package is created with Autoconf version X,
and later automake traces Autoconf version Y to refresh a Makefile.in,
a conflict may appear.]

The above comment opened a new view for me:

In a package using Autoconf and Automake, configure.ac is processed by
autom4te three times:

1) aclocal uses
   autom4te --language=Autoconf-without-aclocal-m4 files... --trace=...

2) autoconf

3) automake calls
   autoconf configure.ac --trace=...

As Alexandre noticed, aclocal.m4 usually is not normally affected by
the Autoconf version, so we don't have to worry if 1) used another
version of Autoconf.

To fix the original problem, we have to make sure that 2) and 3) are
performed by the same version of Autoconf.

I would suffice if autoconf, when called in 3) updated ./configure.
(It presents only minimum of extra work.)

For backward compatibility, autoconf wouldn't touch ./configure if
it hasn't changed in this case.

Technical details:

- automake would call
   autoconf --trace=...
  i.e. the file name would be omitted

- the autoconf specification would be changed:
  -- if no filename is given, configure is always created,
     even when tracing
  -- when tracing and ./configure hasn't changed, the timestamp
     is preserved

Alexandre, what do you think about this solution?
Ralf, is there a chace you will accept this before 2.60?

Have a nice day,
        Stepan