Re: [Automake-ng] [FYI] [ng] maint: use name "Automake-NG" in more places, bump version

[Dave Hart]

On Fri, Feb 17, 2012 at 18:29, Stefano Lattarini
<address@hidden> wrote:
> Well, at first I had thought about using the version number 0.5a, but
> then I realized that doing so would have possibly caused missing
> warnings for projects requiring a minimal Automake API version in
> 'AM_INIT_AUTOMAKE'; for example, a project whose configure.ac contains:
>
>  AM_INIT_AUTOMAKE([1.10])
>
> would (rightfully) trigger a complaint from Automake 1.11.1, but none
> from Automake-NG.  Highly unexpected IMO.  So I took the "short-cut" [1]
> of bumping the Automake-NG version number to avoid this situation.
>
> But then, as you've pointed out, labelling Automake-NG as "2.0" will only
> mud the waters about what the "real" / "more recent" Automake is, and
> cause even more confusion about the Automake vs. Automake-NG distinction.
> Which is precisely what we don't want.
>
> So I now believe that the best way to proceed to avoid the pitfall
> described above is to add a new special "ng" option, that Automake-NG
> will *require* to see in order to proceed; this way:
>
>  - if a user tries to run mainstream Automake on a project requiring
>    Automake-NG, he will see an error from automake about "unknonwn
>    'ng' option";
>
>  - if a user tries to run Automake-NG on a project expecting to be
>    bootstrapped with Automake, he will see a proper complaint from
>    Automake-NG ("this project does not provide an 'ng' option to
>    Automake -- it might not work with Automake-NG, you should use
>    mainstream Automake instead).
>
> I will follow in the next days with a patch providing the version "downgrade"
> (2.0a -> 0.5a) and with another one providing this new 'ng' option.  Of
> course, if someone wants to speed out this steps, patches are welcome.

Excellent, thanks.

>> Congratulations on achieving your original goal.
>>
>> Disgusted,
>> Dave Hart
>>
> Wow, I would have never thought that an apparently innocuous (albeit
> misguided) version bump could cause someone of accusing me of trying to
> purposely derail the Automake project itself :-(

I meant to accuse you of co-opting the future of traditional Automake.

> Maybe, next time, try to be more propositive and less accusatory (not to
> say disrespectful); your aggressive tone has almost caused me to answer
> your badly-expressed but otherwise very sensible objection with a couple
> of snide remarks (which in the end would have hurt you, me, Automake and
> Autoake-NG at the same time).

I am grateful you took the high road.  I'm afraid it's not the first
time I've been accused of being disrespectful or aggressive.  I prefer
to think of it as blunt and to the point, but I also understand how it
can be unpleasant and that it can sometimes backfire.  I am accustomed
to such blunt feedback and do not always appreciate that others may
not be.

I am encouraged by your response that the project I help maintain
won't be left to choose between using an unmaintained tool or imposing
a prerequisite on users anytime soon.

I do recognize the benefits to Automake-NG of leaving behind make
portability in favor of requiring GNU Make.  My concern is quite
selfishly focused on not adding prerequisites to build software I'm
involved in maintaining, which has a long tradition of supporting what
many consider antique and boutique systems.  GNU Make is also highly
portable to such corner-case systems, thankfully.  I have no qualms
with GNU Make, and I'm thankful it includes the bootstrapping script
to compile it without a working make program.  I simply do not wish to
(a) insult my users who are fans of their own make program by implying
it is insufficient to build modern software or (b) see their attempts
to compile my  package stopped with a message telling them to first
compile another package.  I don't mind chasing down such dependencies
as a developer on my development systems, but I recognize what a
disappointment and sometimes block to success such dependencies are to
end users who are compiling not because they write code, but because
they want to run the software.  Selfishly, if people report problems
with 5 to 10 year old snapshots of our project which are no longer
maintained, I want them to be able to grab the latest and greatest and
have as few complications as possible using the code, so that they can
determine if the problem they saw has already been solved without
spending any more of my time than needed.

For the same reason, when we decided to depend on a bleeding-edge
version of a third party library, we chose to bundle that library in
our tarballs as a subproject and worked with the developers of that
library to ease integration such that if the target system has a
recent-enough version of the library installed, we use it, and if not,
we build our subpackage copy for static linking and use that.  This
represented a substantial effort but I believe our users and other
developers using the library benefit, and my selfish goals are served.

Thanks,
Dave Hart