From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v4] OSSTEST: introduce a raisin build test Date: Mon, 18 May 2015 11:54:15 +0100 Message-ID: <5559C4D7.70200@eu.citrix.com> References: <1431422408-16659-1-git-send-email-stefano.stabellini@eu.citrix.com> <1431425547.8263.127.camel@citrix.com> <1431430431.8263.143.camel@citrix.com> <1431507683.8263.212.camel@citrix.com> <1431945198.4944.30.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1431945198.4944.30.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Ian Jackson , "xen-devel@lists.xen.org" , Wei Liu , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 05/18/2015 11:33 AM, Ian Campbell wrote: > On Mon, 2015-05-18 at 11:08 +0100, George Dunlap wrote: >> On Wed, May 13, 2015 at 12:48 PM, 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. >> >> Won't the problem here be disentangling the stuff installed in dist/ >> (or whatever it's called) from the things we want to rebuild vs the >> things we want to change? > > From the osstest PoV at least the proposal here only involves building > additional things, not rebuilding anything which came from a previous > build. > > e.g. given a build of xen.git now do a build of libvirt.git using those > previously built Xen libs. Sure; but what I'm saying is if you do xen-full-build, you'll have a dist/ which contains: * qemut * qemuu * seabios * xen * libvirt * (&c) But when you re-build just libvirt, what you want is a dist/ that contains: * qemut * qemuu * seabios * xen Specifically, you want it *not* to contain anything from the previous libvirt builds. That's what I'm talking about. > Per component dist dirs is similarly surely possible but perhaps not > something raisin wants. You could in theory have per-component "output" directories, and then a global "input" directory which was blown away at the beginning of every raisin build and re-constructed as needed. That would be the sort of equivalent of the mock-style RPM build (where the chroot represents the global "input"). Not sure how well that would work, though. -George