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
