Re: [bug-diffutils] I'd like to release 3.3

[Jim Meyering]

Paul Eggert wrote:

> On 03/21/2013 09:42 PM, Jim Meyering wrote:
>> If anyone has issues for which a release should be delayed,
>> please speak up.
>
> I've had problems with bootstrapping for quite some time
> and that should probably get fixed.
> Bootstrapping doesn't work for me, does it for you?
> Here's what I get:
>
> $ ./bootstrap --gnulib-srcdir=../gnulib
> ./bootstrap: Bootstrapping from checked-out diffutils sources...
> ./bootstrap: consider installing git-merge-changelog from gnulib
> ./bootstrap: getting gnulib files...
> ./bootstrap: getting translations into po/.reference for diffutils...
> rsync: getaddrinfo: translationproject.org 873: Name or service not known
> rsync error: error in socket IO (code 10) at clientserver.c(122) 
> [Receiver=3.0.9]

Hi Paul,

That's odd.  I haven't seen that problem.
It definitely worked fine for me last night.
Network connectivity?

> When I work around that by bootstrapping with --skip-po, I see
> this (autoconf 2.68, automake 1.13.1, gettext 0.18.2):
>
> $ ./bootstrap --gnulib-srcdir=../gnulib --skip-po
> ...
> configure.ac:163: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
> and will soon be removed.
> configure.ac:163: You should use the Autoconf-provided
> AC_PROG_MKDIR_P' macro instead,
> configure.ac:163: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
> Makefile.am files.
>
> Apparently it's overwriting a new version of m4/intl.m4 with an obsolete 
> one...

I haven't investigated that for some time, but thought it was
due to my (personal) use of gettext that's a little older than the
latest, in which I presume that offending macro use has been removed.
I'll install the latest tonight, and see if that resolves the problem.

> These days bootstrap is so complicated and slow
> that I kinda lost track of everything it's doing.
> Maybe it's time to switch to Gary's version, for diffutils?

Is it faster?
Last time I looked, I had reservations:
  - I do not like the idea of more than doubling the line count
  - I found many of the idioms used to be unnecessarily unreadable,
      I'm sure they're fine when your target shell is some least
      common denominator, but not appropriate for a maintainer/developer
      tool where we can (must!) assume a modern shell.

Too bad the python rewrite appears to have fizzled.