bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] README-release improvements


From: Gary V. Vaughan
Subject: Re: [PATCH] README-release improvements
Date: Sun, 23 Oct 2011 13:01:33 +0700

Hi Stefano,

On 23 Oct 2011, at 00:20, Stefano Lattarini wrote:
> Hi everybody.  Just my two cents about this matter ...
> 
> On Saturday 22 October 2011, Bruno Haible wrote:
>> Gary V. Vaughan wrote:
>>>>> Running the (potentially) outdated configure, to build a (potentially)
>>>>> outdated Makefile, which may very well rerun aclocal, automake, autoconf
>>>>> etc just to call the maintainer-clean rule, and then blow it all away
>>>>> in the next step with a bootstrap seems odd and torturous to me.
>>>> 
>>>> The above may be a little wasteful.  But it is reliable and turn-key.
>>> 
>>> No it isn't.
>> 
>> I'm with Gary on this point.
>> 
>> How about these steps?
>> 
>>  make -k maintainer-clean # Clean up previous build artefacts
>>  ./configure
>>  make maintainer-clean    # Clean up previous build artefacts
>>  git checkout master
>>  git pull origin master   # don't try (perhaps fail) to pull other branches
>>  ./bootstrap              # rerun autotools explicitly on latest sources
>>  ./configure              # regenerate Makefile explicitly -"-   -"-
>> 
> At this point, wouldn't it be simpler (and maybe safer) to clone the git 
> repository in a new directory, and simply do "./bootstrap && ./configure"
> from there?

In practice, I prefer to:

  git status
  <save any untracked files I care about>
  git clean -f -x -d
  ./bootstrap --gnulib-srcdir=../gnulib && ./configure --disable-nls

This is way faster, but relies on my discretion.  Like Jim, I'm leary of
recommending git clean in the README-release incase someone follows it and
deletes an important untracked file by mistake.  I think after this pending
patch, README-release offers a safe (if slightly long-winded) recipe for
getting to a clean self-consistent state before bootstrapping in preparation
for a release.

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


reply via email to

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