[Top][All Lists]
[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 12:15:52 +0200 |
Gary V. Vaughan wrote:
> Hi Jim,
>
> On 22 Oct 2011, at 03:06, Jim Meyering wrote:
>> Gary V. Vaughan wrote:
>>> As it stands (without this patch), README-release recommends:
>>>
>>> git checkout master
>>> git pull
>>> ./configure
>>> make maintainer-clean
>>> ./bootstrap
>>>
>>> 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. Imagine that the bootstrap process has changed upstream,
> and that, for example, additional bootstrap steps are needed to fix a
> bug in maintainer-clean. The README-release mandated procedure tells
> you to run the old maintainer-clean rule after potentially merging with
> a new tree that has different requirements. And you don't even rerun
> bootstrap first to ensure that you get a Makefile with a matching
> maintainer-clean rule.
>
> It's very easy to think of a multitude of scenarios where it's not only
> suboptimal but flat out wrong to recommend a full autoreconf run, and
Omitting the "make maintainerclean" step can result in putting
stale generated files in a distribution tarball.
Running things in the wrong order wastes time,
but I see no other ill effect.
E.g., if you remove a gnulib module like parse-datetime,
with rules that run $(YACC). Then, the post-pull bootstrap'd
Makefiles will lack the rule to remove the generated .c file.
People rarely remove modules like that, and even when they do, leaving
around a stray non-distributed file wouldn't hurt anyone. Of course,
it's better not to do that, but unlike omitting "make maintainerclean"
altogether, having a stray .c file in your build directory would not
have an impact on the distributed tarball.
> a second additional configure run just to bring the tree back into a
> semi consistent state that will even allow you to run maintainer-clean
> at all.
>
> If you want to clean the cruft out of your working directories before
> starting the release process, you should do it before you change branches
> and merge changes from upstream, using the Makefile that you already have
> that is already in sync with the rest of your tree:
>
> make maintainer-clean
> git checkout master
> git pull origin master
> ./bootstrap
> ./configure
Yes, running "make maintainer-clean" is a requirement.
A patch with that improvement would be welcome.
- [PATCH] README-release improvements, Gary V. Vaughan, 2011/10/21
- Re: [PATCH] README-release improvements, Stefano Lattarini, 2011/10/22
- Re: [PATCH] README-release improvements, Jim Meyering, 2011/10/22
- Re: [PATCH] README-release improvements, Stefano Lattarini, 2011/10/22
- Re: [PATCH] README-release improvements, Gary V. Vaughan, 2011/10/23
- Re: [PATCH] README-release improvements, Stefano Lattarini, 2011/10/23