Re: [libvirt] [PATCH] build: allow mingw VPATH build
2010/8/14 Eric Blake <eblake(a)redhat.com>:
On 08/14/2010 12:37 PM, Matthias Bolte wrote:
> 2010/8/14 Eric Blake <eblake(a)redhat.com>:
>> * .gnulib: Update to latest.
>> Reported by Matthias Bolte.
>> ---
>>
>> Mainly for the top one, but there are a couple of relevant
>> upstream patches in this list.
>>
>> * .gnulib 1629006...7ba06c8 (152):
>> > pthread: fix pthread.h creation for srcdir != builddir
>
> ACK.
Thanks; pushed.
On a related note: On IRC, you mentioned that you encountered an
inf-loop for make and autogen.sh when you had local modifications in
your .gnulib file. Do you have a simple formula for reproducing that?
If I'm correct, I suspect that autogen and/or bootstrap could be taught
how to recognize whether a 'git submodule update' was sufficient to sync
up to the expected version (the normal case) vs. still noticing that
.gnulib is dirty due to local changes (at least, I'm assuming that was
the situation you were in); in the latter case, it would then be fatal
with a message reminding you to commit your changes so that the
submodule is no longer dirty rather than inf-looping trying to sync up
something that won't change.
I altered .gnulib/modules/pthread in the way the posted patch for
pthread.h did and then run make. I wanted to run make dist after that
to generate a tarball that I could compile in MSys on Windows. This is
faster then building from a general git clone, especially we you need
to update gnulib, because that's really slow in MSys.
make then triggered autogen.sh. I think cfg.mk line 450ff did this;
triggering autogen.sh over and over again because 'git diff .gnulib'
(cfg.mk line 466) printed a diff like this:
$ git diff .gnulib
diff --git a/.gnulib b/.gnulib
--- a/.gnulib
+++ b/.gnulib
@@ -1 +1 @@
-Subproject commit 1629006348e1f66f07ce3ddcf3ebd2d14556cfce
+Subproject commit 1629006348e1f66f07ce3ddcf3ebd2d14556cfce-dirty
cfg.mk could detect such a diff and abort with a fatal message as you said.
Matthias