Hi Jim, On Oct 29, 2013, at 11:54 AM, Jim Meyering <j...@meyering.net> 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
