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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-05-13 at 12:48 +0100, Stefano Stabellini wrote:
> On Wed, 13 May 2015, Ian Campbell wrote:
> > On Tue, 2015-05-12 at 12:46 +0100, Stefano Stabellini wrote:
> > > > Would a separate clone of the same raisin version with some sort of
> > > > "dist" directory transported over be sufficient and supportable? Or are
> > > > raisin's outputs not in one place and easily transportable?
> > > >
> > > > i.e. today build-$ARCH-libvirt picks up the dist.tar.gz files from the
> > > > corresponding build-$ARCH, unpacks them and asks libvirt to build
> > > > against that tree.
> > > 
> > > Moving the dist directory over should work, although I have never tested
> > > this configuration.
> > 
> > Would you be willing to support this as a requirement going forward?
> 
> Yeah, I think it is OK
> 
> > I assume that it is not also necessary to reclone all the trees for the
> > preexisting components, just the new ones?
> 
> Only if the user asks for a components to be built, the corresponding
> tree is cloned.

OK, so the general pattern would be

ts-xen-build:

        Clones raisin
        
        Calls raisin with COMPONENTS="xen seabios qemu qemu-trad"
        # Essentially the current set from xen.git:Config.mk

        Builds xendist.tar and dist.tar from raisin's outputdir
        
ts-foo-build 

        Clones raisin

        Unpacks result of ts-xen-build into $WHERE (and any other
        required components, of which I expect there will be few)
        
        Calls raisin with COMPONENTS="foo"
        
        Builds dist.tar of that 
        
Where the obvious foo right now is libvirt, but eventually would include
grub2 etc. We might also eventually consider moving things out of
ts-xen-build.

I didn't say it, but in both cases there is an implicit "if
$r{use_raisin} else to the old thing fi" there.

The only problem I foresee is that if $WHERE above == raisin's outputdir
then foo's dist.tar would include all of the Xen stuff. How hard would
it be to have those split?

Ian.


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