Re: Automake vs. Automake-NG

[Stefano Lattarini]

On 08/21/2012 02:59 PM, Paolo Bonzini wrote:
> 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.
>
This is not going to happen; some people have strongly objected to such
possibility of a final "takover" of Automake-NG over Automake (and I'm
speaking of people who have been very interested and helpful in the
Automake-NG development so far).  I've come to agree with them in this
respect.

Bottom line is: we want to make it clear that Automake-NG is something
different from Automake -- albeit mostly compatible, deliberately, and
with very, very similar design and API; and that a transition between
the two won't be seamless -- albeit it is expected to be simple and to
involve only little churn.

I'm now writing a new little section to the Automake-NG manual to try to
make this clear and explicit; should be ready today or tomorrow.

> 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
>
This is a good idea.  Want to attempt a patch?  Otherwise, I will write
it myself in the next days.

> * pattern rules should be advertised over suffix rules in Automake-NG,
> but suffix rules should be accepted
>
They are!  It's actually simpler to accept them rather than to reject
them, since doing the latter would entail more Automake-runtime
processing, which we want to avoid.  The only important difference is
that you'll have to declare '.SUFFIXES:' yourself, as Automake-NG do
not do it automatically for you anymore (a change which I now see is
not listed in the NG-NEWS file; will fix shortly).

> * files with non-standard extensions in _SOURCES should be warned about
> in Automake 1.13
> 
Ah, but they are still supported -- it's only that their semantic has
been simplified in Automake-NG, to dump most of the processing on the
shoulders of GNU make.  Banning them would altogether would not be
helpful, and would prevent useful use cases like this:

  %o: %.lisp
        [Our clever rule to compile common lisp to machine code]

  bin_PROGRAMS = foo

  foo_SOURCES = main.lisp opt-parse.lisp features.lisp

> 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 disagree.  After all, people are taking CMake seriously, and that
is hardly compatible with Automake.  What we need the developer to
understand is that:

  - Automake-NG is *not* Automake 2.0, not is meant to become that;
    they must be prepared to deal with incompatibilities.

  - Automake-NG has however *a lot* in common with Automake, so the
    required porting effort will be small; even in the worst scenario,
    significantly smaller than (say) any Automake -> Cmake switch

  - Also, for the same reason, most of the Automake-related knowledge
    an experience a developer might have will be easy recycled into
    Automake-NG.  It's like switching from perl4 to perl5, not from
    perl to python.

> I apologize for the useless complaint if you are already doing this;
>
Please don't.  I find this exchange very useful and informative for my
own understanding of the status and direction of Automake-NG.

> 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.
>
The difference here is that people *should* understand that Automake-NG
is not meant as an "Automake 2.0", but as a new projects with different
aims, and thus different idioms, usages, strengths and weaknesses.

Lots and deliberate similarities as well, but which should not shadow
the differences and make them downplayed and forgotten

This is the point I want to drive home, to avoid another transition
debacle like the Autoconf one.  Here's an honest question: if
Autoconf 2.50 has been called "Autoconf-NG 3.0 alpha", and finally
graduated to "Autoconf-NG 3.0" with what we know as Autoconf 2.60,
do you think the transition would have been less painful (I really
hope the answer is yes, of course).

> 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.
>
Sometimes I'm not anymore sure which is better, honestly :-)

> It can provide good error messages and a clear upgrading path.  Please
> _do_ provide it.
>
I hope to finally do that, but it will be in a form of a how-to and a
set of recipes rather than an attempt to shoehorn Automake-NG semantics
back to Automake.  The latter sounds too slow and too dangerious.

>>> 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.
>
For the moment, we'll agree to differ on this, I say :-)
No hard feelings I hope.

>> Hope I've clarified the situation a bit.
> 
> Me too. :)
>
You have.  I hope I've taken a step further in my side of the
clarification ;-)

Thanks,
  Stefano