Re: a saner bootstrap script

[Gary V. Vaughan]

Hi Jim,

On 5 Oct 2011, at 00:16, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>> On 4 Oct 2011, at 17:09, Jim Meyering wrote:
>>> Do you feel like rebasing it?
>> 
>> Sure, although it will take me a few days to find the time - is that because
>> you're planning to adopt my bootstrap script into coreutils master 
>> unilaterally?
>> If not then you can easily checkout my coreutils snapshot from github to 
>> verify
>> that it is perfectly sane.
>> 
>> Really, I'm trying to help gnulib to adopt the script first and foremost...
>> although the last few Zile releases have been using it, and I'll be making
>> a Libtool release in the next week or so that uses it irrespective of gnulib
>> adoption.  And I expect I'll also put an M4 alpha out with that script too
>> before long.  So, if you want to unilaterally take the script into coreutils
>> too, then I'll be very happy to provide any assistance I can with updating
>> the coreutils bootstrap.conf I wrote all those months ago.
> 
> I'm trying it solely because you've invested so much in it and asked so
> many times.  I'm certainly not chomping at the bit for a new version.

I understand, and appreciate you're making that effort.  Thank you!

> However, I confess that I was disappointed by your rejection of some of
> the style-related suggestions made by Stefano, and have to say that if I
> do use it, the copy I use in coreutils, grep, gzip, patch, parted, etc.
> will inherit most, if not all, of his suggestions.

I'm not at all opposed to style changes by other committers subsequent to
adopting the script into gnulib, and I even volunteered to make the changes
myself if not doing so proved to be a barrier to acceptance.  But, unless I
have to do it, I'd rather not spend my time changing my code out of the
coding style I prefer.  Of course, if the thing is accepted into gnulib then
my personal preferences carry far less weight, and I understand perfectly if
the script is edited into whatever style gnulib developers prefer.

>>>> I just tried to check that everything in my coreutils bootstrap.conf still
>>>> works correctly with coreutils master, but unfortunately coreutils 
>>>> bootstrap
>>>> now requires that I install the latest autotools -- including 
>>>> gettext-0.18.1.1
>>>> which doesn't compile on Mac OS 10.7.1 with the latest Apple supplied gcc
>>>> (4.2.1 LLVM).  And without that, I can no longer bootstrap coreutils on my
>>>> Mac :-(
>>> 
>>> If it's a gettext problem, report it and it should be fixed very quickly.
>>> Otherwise, just adjust the AM_GNU_GETTEXT_VERSION([0.18.1]) line
>>> in configure.ac to accommodate whatever version of gettext you have.
>>> You should be ok if it's 0.17.x.
>> 
>> If an older version of gettext is sufficient, then can you please require
>> that version instead?  Gettext is a large complex package that is quite a
> 
> Using an older version is sufficient to ensure that your script works
> with coreutils.  I don't see why everyone should accept an older version
> just because a build-glitch affects one type of system.  The work-around
> is trivial.

Maybe I misunderstand AM_GNU_GETTEXT_VERSION then?  I thought that it was
to document the minimum compatible version like AC_PREREQ, not to enforce
a specific version.  (Forgive my ignorance: I'm not really a gettext user
since English is my only language, so gettext is just another dependency I
have to build to keep the packages I do use happy, and even then I always
build with --disable-nls to minimise installation of files I'll never use.)

>> At least as far as Mac OS 10.7 is concerned, I tracked the problem down to
>> a bug in the gnulib non-release that was used to bootstrap gettext-0.18.1.1,
>> which has since been fixed in gnulib.
> 
> Again, did you report it?

Yes, I did.  Both on this list and at bug-gnu-gettext, along with a pointer
to the MacPorts patch that got me past the bug.

>> I haven't had time yet to pick up the coreutils bootstrap.conf update, but
>> I'll probably be able to get to it by the end of the week.  If you're in a
>> hurry, then I think you might find writing your own updated bootstrap.conf
>> would be instructive in the vast improvements I think the new bootstrap I've
>> written brings to the table - and maybe help build enough confidence in it
>> that you'd like to help me adopt it into upstream gnulib?
> 
> If I go with it, it will eventually gain at least 10 new client packages.
> However, I don't have a lot of time to invest in the transition,
> so anything you can do to make it easier may go a long way.

And that alone will be a big vote of confidence toward my goal of having it
adopted into gnulib in place of the existing script. I'll ping this thread when
I've finished the update.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)