[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
git hints (cp: cannot create regular file `lib/uniwidth/cjk.h-t': No suc
From: |
Bob Proulx |
Subject: |
git hints (cp: cannot create regular file `lib/uniwidth/cjk.h-t': No such file or directory) |
Date: |
Thu, 1 Nov 2007 11:22:36 -0600 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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 <address@hidden> 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 <address@hidden>
> 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