Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

[Stefano Lattarini]

Hi Paolo, thanks for the reply.

On Tuesday 22 November 2011, Paolo Bonzini wrote:
> On 11/21/2011 09:56 PM, Stefano Lattarini wrote:
> >
> > Here is my tentative plan to act on the proposal:
> >
> >    1. We start requiring GNU make in an "experimental" automake 2.0
> >       development line (which might, and will, break whathever
> >       backward-compatibility gets in its way).
> >    2. Concurrently, we continue to support the more portable (and
> >       tested, and used-in-the-real-world) 1.x line, with bugfixes
> >       at least (and probably also with addition of new not-too-big
> >       features).
> >    3. We publicize this move in the automake (1.x) web pages,
> >       documentation, etc, inviting users and developers to try out
> >       the new "automake 2.0 pre-alpha", and to send cricisims,
> >       suggestions, praise and ranting to the automake lists.
> >    4. Time and user responses decide wether automake 2.0 will
> >       succeed or die out.
> >
> > WDYT?
> 
> It seems very hard to be successful and break backwards-compatibility.
>
Yes, but in the automake case we'd want to break backward-compatibility
to offer better and/or more powerful APIs than the current ones -- whose
limitations and complications are mostly due to the necessity of having
to work with portable make.  To quote the README from the (sadly dead)
Quagmire:

  One general rule in Quagmire is that if there is a simple, generic GNU
  make way to do something, then we don't need special support for it.
  This leads to many differences from the way that Automake does things.
  For instance, in Automake there is a separate quux_CFLAGS variable for
  an aggregate.  In Quagmire, you would instead use a target-specific
  CFLAGS assignment.

> When we introduced shell functions into Autoconf, and in general updated 
> Autoconf/M4sh/libtool for relatively new shells (new = newer than 
> Ultrix), it was successful exactly because no one noticed!
>
Maybe a first step would be to rewrite many (most?) of the automake
internals to take advantage of GNU make features, while retaining
~ 90% of backward compatibility; and only then start to improve the
APIs and, where necessary/conveninent, breaking backward compatibility.

Regards,
  Stefano