Re: [Help-smalltalk] Automake vs. Automake-NG

[Stefano Lattarini]

On 08/21/2012 05:02 PM, Paolo Bonzini wrote:
> Il 21/08/2012 16:32, Stefano Lattarini ha scritto:
>> 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.
> 
> Ok.
> 
>>> * 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.
> 
> I doubt I have time, unfortunately. :(
>
No problem.

>>> * 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).
> 
> Ok.  So the question I'd like you to ask yourself are:
> 
> * Why does it make sense to request manual declaration of '.SUFFIXES:'?
>
I said ".SUFFIXES:"?  Yes, I did.  Oops, my mistake.  What I meant, and
what you must do if you want to remain compatible with mainline Automake,
is to explicitly set the '$(SUFFIXES)' variable.  Mainline Automake would
define that automatically for you (well, most of the times [1] at least),
but Automake-NG will not, since that would require extra automake-runtime
processing.  However both the AUtomake variants will honour an explicit
definition of $(SUFFIXES), and declare '.SUFFIXES:' accordingly [2].

[1] That is, unless you want to generate, say, '.a.b' files from '.c'
    ones, in which case you *must* add '.a.b' and '.c' explicitly to
    said $(SUFFIXES) variable, since the suffix rule:

      .a.b.c:
          ...

    is hopelessly ambiguous.

[2] See how easily Automake-NG can do so:

    $ cat lib/am/footer.am
    ...
    # For better compatibility with mainline Automake.
    $(if $(SUFFIXES),$(eval .SUFFIXES: $$(SUFFIXES)))
    ...

> * Does it make sense to do so in Automake, too?
>
Automake already processes explicit $(SUFFIXES) correctly.  Nothing
to do there.

> * Even if not, could a missing '.SUFFIXES:'
>
[I'm doing 's/.SUFFIXES:/$(SUFFIXES)/' here and blow, in light of what
 said above].

> hide bugs?
>
Not in mainline Automake.

> Would you
> consider adding a warning for missing ".SUFFIXES" in Automake, too?
>
No, because that would be a regression in Automake: until today, it
has been smart enough to initialize $(SUFFIXES) automatically in the
most common (and useful) situations, and stopping doing that for the
sake of a simplified transition to Automake-NG might understandably
annoy that part of the user base that is not interested in such a
transition (at least not now).

> This needs to be done for each NG-NEWS items.  It could improve the
> existing users of Automake, and reduce the size of NG-NEWS.  Both of
> which are good things!
>
And I've done that already where possible and reasonable.  For example,
the 'silent-rules' option is now active by default, and the tags-related
rules have been reworked and improved.  I might consider other similar
backports as well in the future.  But in several areas, similar changes
would risk to cause serious bugs and incompatibilities which, while IMHO
acceptable in a young and still experimental software like Automake-NG,
would not be acceptable in an Automake release.

>>> 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.
> 
> But CMake is not almost the same as Automake, Automake-NG is.
> Automake-NG is not Automake 2.0, but Automake 2.0 _could_ have the same
> user interface as Automake-NG.  What I'm asking is, please consider a
> deprecation path in Automake for _every_ _single_ difference between it
> and Automake-NG.
>
Not doable, sorry.  Some things which are done better, more easily, or
faster in Automake-NG (and which have thus justified a behavioural or
API change) are that way only thanks to the possibility of relying on
GNU make features.  Deprecating the more-complex-and-messier but still
working equivalent (or similar) features and interfaces in Automake
would in the end mutilate it beyond recognition.

> If you rewrote Automake in m4 (only partly kidding), I wouldn't have had
> these objections.  But changing the name doesn't change the perception.
>
Maybe we just need good PR and "advertisment" in this.  The python
developers has managed to make a 3.0 release incompatible with the 2.x
series, because they've been very clear and vocal about the breakage,
and have been for a long time.  We might need to learn from them here,
and maybe we'll succeed.  Any suggestion?

>>> 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.
> 
> People won't. :)
>
>> 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).
> 
> My answer is that the two cases are different.
> 
> On one hand, there was no obstacle between a possible graduation of
> Autoconf-NG 2.5x to Autoconf, like the GNU Make dependency could be for
> Automake-NG.
> 
> On the other hand, it would have been nigh impossible to provide the
> smooth deprecation path that I'm suggesting.
> 
> All I'm saying is, do not release Automake-NG for public use until
> Automake can warn of all incompatible uses, or almost all.
>
As I said, I don't believe this would be actually doable.

>>> 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.
> 
> You have to evaluate each case separately of course, but a single
> project has already shown several cases where Automake _could_ be
> improved this way.
>
Are you referring to the Smalltalk "port"?  If yes, I'm not seeing your
point honestly.  Care to elaborate?

Thanks,
  Stefano