Re: [Automake-NG] [PATCH 6/7] [ng] dist: new API to specify formats of distribution tarballs

[Stefano Lattarini]

On 08/21/2012 06:50 PM, Paolo Bonzini wrote:
> Il 21/08/2012 18:42, Stefano Lattarini ha scritto:
>> On 08/21/2012 06:24 PM, Paolo Bonzini wrote:
>>> Il 12/08/2012 23:20, Stefano Lattarini ha scritto:
>>> Nice, but I'm not sure why this couldn't have a backwards-compatible
>>> replacement.
>>>
>> Because Automake-NG is not meant to be 100% backward compatible.
> 
> I knew you'd say that, but do aim higher than this!
>
I'm not sure I do actually.  My time management is not good enough to
allow for that.  Sorry.

> Trivial and mechanic transitions are still transitions.  And they are
> the easiest to hide in a small snippet like the one below.
>
But that's only part of the story.  As we can see, even in this simple
case we are already getting tangled in the need to provide a preparatory
patch.  And think were to apply it (ng/master or master?).  And it will
need tests, and NEWS entries, and documentation enhancements...  This
will require time, time that can be better spent enhancing Automake-NG
for those users already willing to take some their time to do those
mechanic changes themselves in the first place.

To go from the abstract to the concrete: there is a feature request of
an interested user, which would like to be able to define his own
custom distribution formats in addition to the Automake-provided ones.
The good news is that, given the current state of the Automake-NG
codebase, such an enhancement should be easy to obtain.  And I believe
spending (say) tomorrow morning implementing that feature would be
more useful than spending fighting backward-compatibility glitches.
Especially if they can be trivially overcome anyway with two-line
patches.

>> If the transition from the old interface to the new one is trivial or
>> even mechanic (like in this case IMHO), the old interface will simply
>> be dropped (and a proper explanation and example will added to the
>> NG-NEWS file, unless I stupidly forgot).  Also (as I wrote some days
>> ago in this list, not exactly sure where anymore), I see Automake-NG
>> also as an occasion for de-crufting and API cleanups as well as for
>> feature enhancing and better GNU make integration.
>>
>> that said, however ...
>>
>>> ifeq ($(origin AM_DIST_FORMATS),undefined)
>>> AM_DIST_FORMATS := \
>>>    $(patsubst dist-%, %, $(filter dist-%, $(AUTOMAKE_OPTIONS)) \
>>>    $(if $(filter no-dist-gzip, $(AUTOMAKE_OPTIONS)),,gzip)
>>> endif
>>>
>> ... this is small and self-contained enough that I will accept and
>> integrate it, if wrapped in a nice patch ;-)  And since we'll leave
>> it undocumented and "use at your own risk", not need to bother with
>> testsuite additions for once (just add a warning in a comment saying
>> that the code fragment is untested).
> 
> Undocumented != untested.  It should definitely be tested.
>
Obviously I won't reject a test ;-)  I was just saying I wouldn't require
one as a prerequisite to accept a patch -- not in this case.

>> Oh, and if you go this route, the errors given in 'Options.pm' at the
>> sight of 'dist-*' and 'no-dist-*' options will need to be downgraded
>> to warnings in the 'obsolete' category ...
>>
>>> This requires Automake-NG to merge AM_INIT_AUTOMAKE's arguments into
>>> the Makefile.in's AUTOMAKE_OPTIONS, which is only goodness.
>>>
>> This might be done in a follow-up though.  A project wanting to keep the
>> difference between its Mainline-Automake and Automake-NG build systems
>> at a minimum can move the 'dist-*' options from AM_INIT_AUTOMAKE into
>> AUTOMAKE_OPTIONS in a preparatory patch anyway ...
> 
> Can we do this change in Automake 1.13 instead?  It sounds easier to do
> it that way and get it merged into Automake-NG, even though for 1.13 it
> is just cosmetic.
>
We can.  I know we are probably going to hate me for this, but ...
patches welcome.

Regards,
  Stefano