Re: [Xen-devel] [PATCH v4] OSSTEST: introduce a raisin build test

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-05-18 at 14:23 +0100, George Dunlap wrote:
> On 05/18/2015 02:14 PM, Ian Campbell wrote:
> >> That solves the most general case; but it sounds like you care mostly
> >> about the very specific case of dealing with components that depend on
> >> the current output of xen.git.  Starting simple may be fine.
> > 
> > Currently we only have ts-*-build things which depend on the output of
> > ts-xen-build (in fact, we only have ts-libvirt-build).
> > 
> > I'm not sure if there will be others in the future, I suppose
> > ts-rump{qemu,xenstore,foo}-build -> ts-rumpkernel-build -> ts-xen-build
> > might eventually be a possibility...
> 
> I guess I was assuming that at some point you might have the following
> builds and dependencies (not sure these are all correct):
>  ts-seabios-build: [none]
>  ts-qemut-build: [none]
>  ts-qemuu-build: ts-seabios-build
>  ts-xen-build: ts-qemut-build ts-qemuu-build
>  ts-libvirt-build: ts-xen-build
>  &c

NB: ts-xen-build depends on ts-seabios-build directly, not via
ts-qemu?-build since the BIOS becomes part of hvmloader not qemu.

I think ts-xen-build <-> ts-qemu?-build is a little circular today in
xen.git (qemu uses libxenctrl), but building ts-xen-build first (i.e.
reversing the deps you have there) is how I would solve that (and I
expect raisin did so).

> I'm not arguing for this, I'm just trying to explain the problem I was
> initially trying to solve. :-)
> 
> But as we don't have any tests for seabios and qemu* in isolation, I
> guess it doesn't really make sense to treat them separately.

It could very well eventually make sense to split up things which used
to be part of the monolithic xen.git build into separate builds. qemuu
would be an ideal candidate, for example.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel