Since use of git is still new to many people on the list I thought I reply with some general git hints for folks that might be following along. If you are already a git wizard then this won't be interesting to you.
Jim Meyering wrote: > Andreas Schwab <[EMAIL PROTECTED]> wrote: > > A freshly checked out tree fails to bootstrap. > > Thanks for reporting it. > I noticed not long after the gnulib change that provoked it, > and Bob Proulx tracked it down to this seemingly-innocuous change: > > commit d5daff19f4a26e67e7c410cefa9ddc13e036162a > Author: Bruno Haible <[EMAIL PROTECTED]> > Date: Mon Oct 29 12:55:44 2007 +0100 > > If --lgpl is not specified, convert copyright headers to GPLv3+. Individual commits can be viewed using the git-show command. Either the full commit signature or enough to be unique. I am just going to use the first few characters here. $ git show d5daff19 ...patch-like output... This will be automatically piped to your pager (in my case 'less') and so it is not necessary to explicitly pipe it to one. > Although a gnulib change provoked the failure, I think bootstrap > needs to change now that cjk.h is generated via a different code path, > but haven't looked into it yet. > > For now, you should be able to work around it by doing this first: > > mkdir lib/uniwidth Or alternatively since there are only three commits in the upstream gnulib since this failure I have simply been building using the previous version of gnulib from version control. In my mind the whole purpose of version control is to create a safety net so that when a new change causes a problem that it can be easily dealt with by using previous known good versions. Since I am building with a separate gnulib in its own directory the version of gnulib can be selected separately from the version of coreutils. I am building coreutils using the './bootstrap --gnulib-src=../gnulib' option. $ cd ../gnulib $ git checkout -b gnulib-ss-working d5daff19^ By using '^' at the end this checks out the version above/before that version. This selects the last version that built successfully. This could easily have been 28d9a006 too since d5daff19^ means 28d9a006 in the gnulib history. (And of course the full long commit signature could have been used, as from a cut-n-paste, too. I just shortened it to make this message more readable.) The 'git-checkout -b gnulib-ss-working' creates a branch and names it "gnulib-ss-working". This is necessary because git requires this to be a branch head where more versions _could_ be committed and the original "master" head already has commits after this point in the branch and so a new branch just to hold this must be created. When the gnulib problem is resolved this can be pulled back up to the latest "HEAD" of the branch. $ git checkout master After returning to the master branch's HEAD version the "topic branch" is no longer needed. It can be removed to clean it up. $ git branch -d gnulib-ss-working Using git to find these types of failures is made easier by the git-bisect command in git. This command handles the topic branches during the reduction process automatically. The idea is that if you have a point in time where things are one way (let's say working) and another point in time where things are another way (say not working) then you can perform a binary search through the list of versions between those two points and very quickly find the version where things change with a very few number of build attempts. I knew cd6b82c9 was a good version and planned to start the search there. git-rev-list cd6b82c9..master | wc -l 18 With 18 potential versions to test I wanted to reduce the number of potential build and test cycles and used git-bisect. Here is how a typical session goes. $ git checkout master $ git bisect start $ git bisect bad HEAD $ git bisect good cd6b82c9 Bisecting: 9 revisions left to test after this ...test... $ git bisect good Bisecting: 5 revisions left to test after this ...test... $ git bisect good Bisecting: 2 revisions left to test after this ...test... $ git bisect bad Bisecting: 1 revisions left to test after this ...test... $ git bisect good d5daff19f4a26e67e7c410cefa9ddc13e036162a is first bad commit ...use this version for a bit... Out of 18 versions the change was found in four test cycles. At any time during the testing you can invoke 'git-bisect visualize' to start up a 'gitk' visualizer to display graphically the versions that are in the suspected version list. This operates on a "bisect" branch. When done use 'git bisect reset' to clean up and return to the master branch on the branch head. $ git bisect reset # all done Bob _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils