bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a saner bootstrap script


From: Gary V. Vaughan
Subject: Re: a saner bootstrap script
Date: Tue, 4 Oct 2011 18:52:51 +0700

Hi Jim,

On 4 Oct 2011, at 17:09, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>> Sorry I didn't notice your reply sooner.
>> 
>> On 22 Sep 2011, at 23:38, Jim Meyering wrote:
>>> Gary V. Vaughan wrote:
>>>>>> * address@hidden:gvvaughan/GNU-coreutils.git in gary/bootstrap
>>>>>> https://github.com/gvvaughan/GNU-coreutils/commits/gary/bootstrap
>>> 
>>> I'll try to find time for this next week.
>> 
>> Thanks.  How did you get on?
> 
> Hi Gary,
> 
> I started looking, but found that your bootstrap.conf is
> months old, and thus not usable with the current sources.

Indeed.  Although the idea was to prove that my bootstrap works well by
writing a series of bootstrap.conf for a selection of GNU projects with
different bootstrap requirements... and much less to provide bootstrap.conf's
for the projects I chose for that demonstration. And I wasn't really expecting
to wait 14 months for it to be adopted into gnulib, and didn't anticipate the
ongoing development in those projects would make my demo bootstrap.confs
obsolescent :(

> 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 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
challenge to compile on some of the architectures we support at times.

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.  Rather than trying to rebootstrap
gettext to pick up the fix, and have to worry about other problems that
might bring, I hand-applied the patch to gettext configure, and was able to
build a new enough gettext.

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?

>>> I glanced through the first few lines of your script and found
>>> 
>>> FGREP=fgrep
>>> EGREP=egrep
>>> ...
>>> 
>>> Please use the more standard grep -F and grep -E instead.
>> 
>> I wasn't aware that it was more portable to expect a vendor grep that
> 
> egrep and fgrep have been deprecated for years.
> POSIX stopped requiring them back in 1003.1-2001.
> Since they have not been required for POSIX-conformance for 10 years...

Interesting.  Thanks for the info, I should probably try to pay more attention
to the goings on at Austin Group and POSIX rather than just pragmatically
checking what works on the 30 or so platforms I support.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]