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 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.



reply via email to

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