[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] raisin and minios stubdom
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@xxxxxxxxxxxxx> > >>>> 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? 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. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |