Re: git head fails to build

[Neil Jerram]

2009/1/14 Ludovic Courtès <address@hidden>:
> Hello Neil,
>
> I've been working on this in parallel, so I thought it'd be better to
> get in sync.  ;-)

Thank you!

> I had (hopefully) fixed the problem by reverting your commits in reverse
> order and starting anew (attached patch).  The problem is that commit
> 4a462e35440fdc3f10b0f88b3fb737fa76ed146d touches way too many files: it
> adds generated `.h' files (which is boring since they then have to be
> removed before one can `pull' or `checkout'), it modifies
> `m4/.gitignore' (which we don't want precisely because we commit
> Gnulib's M4 files), it adds `lib/.gitignore', it modifies `INSTALL',
> etc.

Right.  Since my last message, I realized that Gnulib by default is
assuming that one won't commit its files, and hence it adds them to
.gitignore.

> I find it tricky to update Gnulib files since we store them in the repo.
> It's easy when one doesn't store them in the repository because it
> updates `.gitignore', etc., but it gets harder when one stores them in
> the repo.  We should use "gnulib-update --no-vc-files" actually (info
> "(gnulib) VCS Issues"), but we still have to make sure we don't commit
> generated files.

Cool, I'll try to remember that in future.

Your patch looks good - except that we should also delete
libguile/alloca.c.  I can do that in a separate commit if you prefer.

I was on the point of reaching the same endpoint, by doing
$ rm *
$ git checkout master -- .
$ ../../gnulib/gnulib-tool -- import
<edit lib/.gitignore and m4/.gitignore so that they are empty>
$ git status
And then the git status output tells you which Gnulib files should be committed.

But given that your patch is ready to go, please commit it.

         Neil