bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] README-release improvements


From: Jim Meyering
Subject: Re: [PATCH] README-release improvements
Date: Sat, 22 Oct 2011 14:43:24 +0200

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.

And so am I.
My objection was to the *removal* of the "make maintainer-clean" step.
I guess you didn't see the reply where I said a patch moving it to
precede the checkout+pull would be welcome.

> How about these steps?
>
>   make -k maintainer-clean # Clean up previous build artefacts

Adding the -k is good, too.

>   ./configure
>   make maintainer-clean    # Clean up previous build artefacts

What's the point of rerunning configure and maintainer-clean?
I can see doing that if the make -k ... failed, e.g.,

    make -k maintainer-clean || { ./configure && make maintainer-clean; }

but not unconditionally.
Some other reason?

>   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 -"-   -"-
>
> Doing the "make maintainer-clean" with the old Makefiles is the most
> reliable you can do.
>
> Now this sequence takes a little more time than what you proposed, Jim.
> But it's only needed once before the release. You don't object to the
> time it takes to run "make distcheck" either.



reply via email to

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