Xen project Mailing List

On 01/04/17 08:19, Géza Gémes wrote:
>
>
> 2017. márc. 31. 16:15 ezt írta ("Juergen Gross" <jgross@xxxxxxxx

> <mailto:jgross@xxxxxxxx>>):

>
> On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
> > On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
> >>
> >>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
> >>>> Hi,
> >>>>
> >>>> Currently the xen build system has optional support for
> building a minios
> >>>> (+needed libraries and tools) based stubdom.
> >>>>
> >>>> What is your opinion about moving support for building this
> into raisin and
> >>>> once that is stable drop support in the xen build system?
> >>> Why? I do like doing 'make' and 'make install' and it doing
> everything
> >>> for me.
> >>>
> >>>> Cheers,
> >>>>
> >>>> Geza
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Xen-devel mailing list

> >>>> Xen-devel@xxxxxxxxxxxxx <mailto:Xen-devel@xxxxxxxxx.org>
> >>>> https://lists.xen.org/xen-devel <https://lists.xen.org/xen-devel>

> >>
> >> Because it means that xen build needs to download and build a lot
> of 3PP
> >> components. Raisin is already designed to do so (it already
> builds qemu-xen,
> >
> > If you do 'make src-tarball' it will do that for you - and you can
> package
> > all of that in a tarball.
> >
> >> qemu-traditional, libvirt and a few others). I think building
> anything
> >> besides xen proper would fit its scope better.
> >
> > OK, but that does not square well with RPM build systems. Those
> are interested
> > in building just one component (xen+toolstack+its extra pieces). Using
> > raisin to build everything is not going to fly.
> >
> > (Also distros like to seperate componets out - so they build
> qemu-upstream
> > seperate - which is used by Xen - and they could also do it for MiniOS
> > if they were spec files for it and such).
>
> There are only few stubdoms you can build without the Xen tree. How
> would you do so for e.g. xenstore-stubdom needing the Xenstore sources
> to be built? Several stubdoms need libxc built for stubdom included.
> And you want to have a build error if e.g. a libxc modification is
> breaking stubdom build.
>
>
> Juergen
>
> Hi,
>
> Raisin already builds xen too, so it has all the dependencies ready.
> Regarding the problem of breaking stubdom build by libxc changes I think
> those can be prevented if we introduce osstests for raisin build. Maybe
> we should start with that, adding raisin to the osstest framework.
> Opinions?

osstest is too late. I want to see a build error _before_ sending a
patch.

So how is raisin working exactly? Is it possible to do incremental
buils or is the build always complete? Can I start builds of only a
subtree? Is it possible to use a private version of some sub-component?

You can use private versions easily. Regarding the problem of selective rebuild O think that is missing currently, but given your input it looks important, so I'll look for ways to enable it.

I'm not opposed to use raisin e.g. in osstest. I'm opposed to a change
in the developer workflow requiring to spend either much more time for
testing the build or to add additional steps for it. One-time changes
are fine, changes requiring the developer not to forget an additional
command are not.

As raisin is able to build xen and a set of related projects it is practically a matter of running raise build rather than make.

Juergen

Cheers

Géza

Re: [Xen-devel] raisin and minios stubdom