Re: Automake vs. Automake-NG

[Paolo Bonzini]

Il 21/08/2012 14:44, Stefano Lattarini ha scritto:
> But there is an important difference: Automake-NG is *not* the next
> version of Automake, it is the "Next Generation": it's not meant to
> be merged into the Automake code base, nor to supersede Automake,
> because the two projects have different "mission statement":
> 
>   - Automake: allow the user to write Makefiles portable to different
>     systems *and* make implementation, and help him to *avoid* using
>     GNU make specific features would hurt portability,
> 
>   - Automake-NG: allow the user to write Makefiles portable to
>     different systems *but* tailored for modern GNU make, and allow
>     them to take *full advantage* of GNU make features whenever
>     possible (which is less than we'd like, due to the code base
>     and design inherited from mainline Automake).
> 
> Automake-NG might finally supersede Automake when *and if* the great
> majority of developers using the the Autotools agree that porting to
> non-GNU make is not worth anymore; but that will not mean that
> Automake has been merged into Automake-NG, merely that a change in
> portability requirements have made it obsolete.  That's very important
> to understand.

Understood.  On the other hand, Automake-NG should strive as much as
possible for backwards-compatibility, so that the obsolescence of
Automake comes naturally, and requires as little manual intervention as
possible.  If one day Automake-NG 0.99 "happens to become" Automake 2.0,
people should not notice.

For this reason, as much deprecation as possible should occur in both
code bases.  Looking at the GNU Smalltalk patches you sent:

* using INCLUDES instead of AM_CPPFLAGS could be deprecated loudly in
Automake 1.13

* pattern rules should be advertised over suffix rules in Automake-NG,
but suffix rules should be accepted

* files with non-standard extensions in _SOURCES should be warned about
in Automake 1.13

This way, people will slowly convert their code bases to the style
preferred for Automake-NG.  If the only point that remains is the
variable typo detection, that's fine.  But all semantic changes should
be suggested by (non-NG) Automake for developer to even consider taking
Automake-NG seriously, IMHO.

I apologize for the useless complaint if you are already doing this;
please let me explain my worries.  The lack of a clear upgrading path
(and bugs in autoupdate, which took a while to get right) was what
caused problems in Autoconf 2.50-2.53, compounded by the lack of
awareness about Autoconf/m4 best practices.

Now the latter has not changed much; try-and-see-debugging is still in
wide use for Autotools (and that is the reason for so many
Autotools-related flamewars).  But (non-NG) Automake is Perl, not m4.
It can provide good error messages and a clear upgrading path.  Please
_do_ provide it.

>> Another choice is to find AC_SUBSTed variables that end with LDFLAGS,
>> CPPFLAGS, CFLAGS, etc., and whitelist them automatically.  It can be
>> done in m4, from Automake-NG's macros.
>>
> I'm still not sold on this.  What if a user have "foobar" in
> bin_PROGRAMS, and then do something like this in its configure.ac:
> 
>   if something; then
>     AC_SUBST([foobar_LDFLAGS], [-lzap])
>   else
>     AC_SUBST([foobaz_LDFLAGS], [-lmu])
>   fi
> 
> I think a warning about "no program or library named 'foobaz'" is
> still warranted here.

Yeah, and that's why I initially proposed whitelisting all-uppercase
variables.  It's a convention, but it's a common convention.  Programs
are rarely if-ever all-uppercase.  Libraries never are due to the _a or
_la suffix.

> Hope I've clarified the situation a bit.

Me too. :)

Paolo