All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH v4] OSSTEST: introduce a raisin build test
Date: Mon, 18 May 2015 11:33:18 +0100	[thread overview]
Message-ID: <1431945198.4944.30.camel@citrix.com> (raw)
In-Reply-To: <CAFLBxZYpyq-bvsMVTYuPFTp2ro192JqZsw8LsgJPm4Tqe7=row@mail.gmail.com>

On Mon, 2015-05-18 at 11:08 +0100, George Dunlap wrote:
> On Wed, May 13, 2015 at 12:48 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> 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.

But there is still the issue of separating stuff built in Pass-A from
the stuff in Pass-B.

Raisin could presumably have a concept of two dist dirs, dist.base and
dist with the former being r/o. But that sounds to me like the sort of
thing you wouldn't want in Raisin.

Per component dist dirs is similarly surely possible but perhaps not
something raisin wants.

> I.e., ideally if you want to build just xen.git, you want dist/ to
> contain the output of the previous build of seabios, qemut, qemuu, &c,
> but *not* the output of previous xen.git builds (or, ideally, the
> output of previous libvirt, pvgrub, or stubdom builds).  Just tar and
> untarr'ing dist/ after a full build won't accomplish that.
> 
> Would it make sense to do some sort of "save snapshot" functionality
> that would tar up the dist/ before building a particular component,
> such that it could be used later?  Sort of a "stage 2*" for raisin.
> :-)
> 
>  -George
> 
> * Referring to Gentoo.  Not sure the comparison is 100% accurate.

  reply	other threads:[~2015-05-18 10:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12  9:20 [PATCH v4] OSSTEST: introduce a raisin build test Stefano Stabellini
2015-05-12 10:12 ` Ian Campbell
2015-05-12 11:16   ` Ian Jackson
2015-05-12 11:20   ` Stefano Stabellini
2015-05-12 11:33     ` Ian Campbell
2015-05-12 11:46       ` Stefano Stabellini
2015-05-13  9:01         ` Ian Campbell
2015-05-13 11:48           ` Stefano Stabellini
2015-05-13 11:57             ` Ian Campbell
2015-05-18 10:08             ` George Dunlap
2015-05-18 10:33               ` Ian Campbell [this message]
2015-05-18 10:54                 ` George Dunlap
2015-05-18 11:21                   ` Ian Campbell
2015-05-18 13:05                     ` George Dunlap
2015-05-18 13:14                       ` Ian Campbell
2015-05-18 13:23                         ` George Dunlap
2015-05-18 13:32                           ` Ian Campbell
2015-05-18 13:33                         ` Ian Jackson
2015-05-18 13:46                           ` Ian Campbell
2015-06-17 14:13                       ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1431945198.4944.30.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.