[Top][All Lists]

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

Re: 2.4 Release in 24hrs

From: Charles Wilson
Subject: Re: 2.4 Release in 24hrs
Date: Tue, 21 Sep 2010 23:01:05 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

On 9/21/2010 9:21 PM, Gary V. Vaughan wrote:
> I don't recall having done so in a while but, according to bootstrap:
> # It is okay for the bootstrap process to require unreleased autoconf
> # or automake, as long as any released libtool will work with at least
> # the newest stable versions of each.  Generally, newer versions offer
> # better features, and documents oldest version of each
> # required for bootstrap (AC_PREREQ, and AM_INIT_AUTOMAKE).
> And in the release template in HACKING:
> You will then need to have recent (possibly as yet unreleased) versions
> of Automake and Autoconf installed to bootstrap the checked out
> sources yourself.
> So, I will install git automake at the front of my PATH, and if the
> release process works, then I'll go ahead and use it for the release.

OK.  If it's documented, then that's fine.

> Is there a better way to save rebootstrappers from accidental
> downgrade than specifying AM_INIT_AUTOMAKE([1.11a]) in libtool's
>  Pity Automake doesn't use gnulibs `git-version-gen' so
> that I could specify the particular revision with the compile script
> patch that we want at libtool bootstrap time.

Well, now that I think about it, it doesn't REALLY matter (to me).  The
only case, at this time, in which you need the compile script IN libtool
to be latest-n-greatest is if you are building libtool itself using
cl.exe/MSVC.  I'm not. doesn't matter if I "downgrade" the
compile script by rebootstrapping with released automake.


reply via email to

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