Re: [PATCH] maint.mk: get current gnulib revision correctly.

[Gary V. Vaughan]

Hi Jim,

On Oct 29, 2013, at 11:54 AM, Jim Meyering <address@hidden> wrote:

> I will soon push the following change, followed by another that will add
> this line
> 
>  (unset CDPATH) >/dev/null 2>&1 && unset CDPATH
> 
> near the top of gnulib-tool.  That CDPATH-unsetting change is the accepted
> approach to rendering "cd" sensible, i.e., making it emit nothing
> to stdout.  Thus, there is no need to redirect stdout for every single
> use of the "cd" shell builtin.

Agreed on all counts, and while I like your followup patch, it’s still a
real problem that bootstrap (a maintainer tool) makes a shallow gnulib clone,
and ‘make release’ (a maintainer rule) currently fails (and after your patch
instead behaves differently) in the face of a shallow clone.

> Gary, I suggest that you avoid using shallow clones of gnulib.  Surely
> you have at least one full clone, and with that, you can reference that
> clone from any subsequent bootstrap, thus avoiding the network/disk hit
> of cloning from scratch.

Well certainly, now that I know the shallow clones are the problem, I
can sidestep bootstrap and manually copy a gnulib subproject.  But I’d much
prefer that the following works by default:

  $ ./bootstrap —gnulib-srcdir=$HOME/Devo/gnulib--master—HEAD
  $ ./configure
  $ make distcheck
  $ make release RELEASE=‘2.4.3 stable’

It may be that my bootstrap rewrite makes a shallow clone more often than
gnulib bootstrap, but if the solution is to not make shallow clones, then
both bootstraps need to be fixed.

> Also, for subsequent commits, please follow our convention of adding
> an entry in ChangeLog that is equivalent to your commit log (you forgot
> that for the commit I am partially reverting).

Sorry about that.  Gnulib is the last project I contribute to that has
a manually maintained ChangeLog, so I’m out of the habit.

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

signature.asc
Description: Message signed with OpenPGP using GPGMail