Xen devel - Oct 2010 - [PATCH] refetch qemu if QEMU_TAG changed

Check for a changed QEMU_TAG. If it has changed since last build, delete old
qemu sources and refetch with new QEMU_TAG.

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 8 insertions(+)
tools/Makefile |    8 ++++++++




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2010-10-29 at 07:57 +0100, Juergen Gross wrote:
> Check for a changed QEMU_TAG. If it has changed since last build, delete
old
> qemu sources and refetch with new QEMU_TAG.
Deleteing and recloning seems like an awfully big hammer. Can the same
not be achieved with a "git fetch origin" and a "git reset
<tag>"?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/29/10 09:20, Ian Campbell wrote:
> On Fri, 2010-10-29 at 07:57 +0100, Juergen Gross wrote:
>> Check for a changed QEMU_TAG. If it has changed since last build,
delete old
>> qemu sources and refetch with new QEMU_TAG.
>
> Deleteing and recloning seems like an awfully big hammer. Can the same
> not be achieved with a "git fetch origin" and a "git
reset<tag>"?
I''m no git expert :-)
I just created an automated version of the currently supported
"official" way
to handle this kind of problem (make distclean) without deleting everything.

I don''t know if there are any nasty side effects possible with your
proposal,
so it would be nice if someone with more git experience could set up a better
solution.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Friday, 29 October 2010 at 08:20, Ian Campbell wrote:
> On Fri, 2010-10-29 at 07:57 +0100, Juergen Gross wrote:
> > Check for a changed QEMU_TAG. If it has changed since last build,
delete old
> > qemu sources and refetch with new QEMU_TAG.
> 
> Deleteing and recloning seems like an awfully big hammer. Can the same
> not be achieved with a "git fetch origin" and a "git reset
<tag>"?
In any case, it should probably only do that if the currently
checked-out version matches the old value of QEMU_TAG and the
directory has no source modifications, indicating the builder is just
using the default build. Otherwise it should just warn that QEMU_TAG
has changed and the ioemu directory may have become out of date.

With the proposed patch it''s very easy to destroy a
developer''s code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2010-10-29 at 17:12 +0100, Brendan Cully wrote:
> On Friday, 29 October 2010 at 08:20, Ian Campbell wrote:
> > On Fri, 2010-10-29 at 07:57 +0100, Juergen Gross wrote:
> > > Check for a changed QEMU_TAG. If it has changed since last build,
delete old
> > > qemu sources and refetch with new QEMU_TAG.
> > 
> > Deleteing and recloning seems like an awfully big hammer. Can the same
> > not be achieved with a "git fetch origin" and a "git
reset <tag>"?
> 
> In any case, it should probably only do that if the currently
> checked-out version matches the old value of QEMU_TAG and the
> directory has no source modifications, indicating the builder is just
> using the default build. Otherwise it should just warn that QEMU_TAG
> has changed and the ioemu directory may have become out of date.
> 
> With the proposed patch it''s very easy to destroy a
developer''s code.
Quite right, I hadn''t considered that aspect.

The following patches adds an explicit update mechanism, which isn''t
brilliant but is better than doing "cd tools/ioemu-remote && git
reset
--hard <sha1...>" by hand.

For the old hg clone integration for linux-2.6.18-xen.hg (the stuff in
buildconfigs/*) we had XEN_LINUX_UPDATE which forced an update when set
to y. I don''t know that was widely used (or indeed known about).

Your suggested warning when the tree differs from the preferred tag
would be a useful and complimentary improvement.

Ian.

diff -r b491f46546d5 -r 7228faad83f5 Makefile
--- a/Makefile	Tue Nov 09 14:12:41 2010 +0000
+++ b/Makefile	Tue Nov 09 14:12:41 2010 +0000
@@ -82,6 +82,10 @@ endif
 
 tools/ioemu-dir:
 	$(MAKE) -C tools ioemu-dir-find
+
+.PHONY: tools/ioemu-dir-force-update
+tools/ioemu-dir-force-update:
+	$(MAKE) -C tools ioemu-dir-force-update
 
 .PHONY: install-docs
 install-docs:
diff -r b491f46546d5 -r 7228faad83f5 tools/Makefile
--- a/tools/Makefile	Tue Nov 09 14:12:41 2010 +0000
+++ b/tools/Makefile	Tue Nov 09 14:12:41 2010 +0000
@@ -110,6 +110,14 @@ ioemu-dir-find:
 		cd ioemu-dir; \
 		./xen-setup $(IOEMU_CONFIGURE_CROSS)
 
+.PHONY: ioemu-dir-force-update
+ioemu-dir-force-update:
+	set -ex; \
+	if [ "$(QEMU_TAG)" ]; then \
+		cd ioemu-remote; \
+		$(GIT) reset --hard $(QEMU_TAG); \
+	fi
+
 subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find
 
 subdir-clean-ioemu-dir:




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Campbell writes ("Re: [Xen-devel] [PATCH] refetch qemu if QEMU_TAG
changed"):
> The following patches adds an explicit update mechanism, which
isn''t
> brilliant but is better than doing "cd tools/ioemu-remote &&
git reset
> --hard <sha1...>" by hand.
This seemed like a step in the right direction, so I wrote a commit
comment, signed it off, and applied it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel