Re: [PATCH] README-release improvements

[Jim Meyering]

Gary V. Vaughan wrote:
...
>>> -* Run ./configure && make maintainer-clean
>>
>> Why do you want to remove the "make maintainer-clean"?
>> I saw no justification, so maybe it's an accident.
>
> Hmm... half and half. Here's the relevant bit of ChangeLog:
>
> +     Don't try to run ./configure right after git pull incase files
> +     that influence the bootstrap process have changed, move the
> +     ./configure step to after running ./bootstrap.

That does not justify the removal of "make maintainer-clean".

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

If you know you've run "make maintainer-clean" recently, and you know
that none of the tools that will regenerate key bits have changed (hard
to know, though), then it's ok to skip.  It's not worth the risk, to me.
I don't make releases frequently enough to worry about a few minutes of
CPU time, even if it's only for a minimal thing like this.

I want a list of rules that I can follow with a minimum of thinking.
Ideally it would be scripted, but we can save that for another day.

> Worse,
> the next time you try to run make after the final bootstrap step, some
> or all of the autotools will have to run again to regenerate the Makefile.
>
> This patch reorders the steps thus:
>
>   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 -"-   -"-
>
> If you want to remove any file-droppings, you can use rm or git clean, or
> make maintainer-clean as and when it fits the situation your working tree
> is in. I didn't want to put an explicit git clean step in for fear of

Using git clean here is not an option.
And manually running "rm" is obviously not maintainable.
Add a new gnulib module and you may easily pull in rules to
generate files that only "make maintainer-clean" will remove.

If you really dislike burning the extra CPU cycles, patch
the procedure for your projects.