Re: [XEN PATCH v7 00/51] xen: Build system improvements, now with out-of-tree build!

From: "Alex Bennée" <alex.bennee@linaro.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
	"Kevin Tian" <kevin.tian@intel.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Ian Jackson" <iwj@xenproject.org>,
	"Connor Davis" <connojdavis@gmail.com>,
	"Bob Eshleman" <bobbyeshleman@gmail.com>,
	"Alistair Francis" <alistair.francis@wdc.com>,
	"Tim Deegan" <tim@xen.org>,
	"Jun Nakajima" <jun.nakajima@intel.com>,
	"Tamas K Lengyel" <tamas@tklengyel.com>,
	"Doug Goldstein" <cardoe@cardoe.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Julien Grall" <julien@xen.org>,
	"Alexandru Isaila" <aisaila@bitdefender.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Ross Lagerwall" <ross.lagerwall@citrix.com>,
	"Petre Pircalabu" <ppircalabu@bitdefender.com>,
	"Paul Durrant" <paul@xen.org>,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Wei Liu" <wl@xen.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Lukasz Hawrylko" <lukasz.hawrylko@linux.intel.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v7 00/51] xen: Build system improvements, now with out-of-tree build!
Date: Thu, 04 Nov 2021 16:59:39 +0000	[thread overview]
Message-ID: <87k0hnj1gv.fsf@linaro.org> (raw)
In-Reply-To: <YYQLoR2ussToQjFV@perard>

Anthony PERARD <anthony.perard@citrix.com> writes:

> On Thu, Nov 04, 2021 at 03:49:36PM +0000, Alex Bennée wrote:
>> 
>> Anthony PERARD <anthony.perard@citrix.com> writes:
>> 
>> > Patch series available in this git branch:
>> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxenbits.xen.org%2Fgit-http%2Fpeople%2Faperard%2Fxen-unstable.git&amp;data=04%7C01%7Canthony.perard%40citrix.com%7C85bb0d32a72542aa9f6108d99fad9607%7C335836de42ef43a2b145348c2ee9ca5b%7C0%7C0%7C637716390172120458%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WWS4yPu9%2BJxBkBiM5SBrH7kDtHkUzMGuKSSdPcgEYII%3D&amp;reserved=0
>> > br.build-system-xen-v7
>> >
>> > v7:
>> >     Out-of-tree build!
>> >
>> >     This mean many more patches. Everything after patch 27 is new.
>> >
>> >     There's a few new patch before that, but otherwise are rework of
>> >     v6.
>> 
>> This is something I've been looking forward to but obviously my QEMU
>> focused mind meant I did it wrong. Generally I create a builds subdir in
>> my tree with subdirs for each build flavour. So with:
>> 
>>   /home/alex/lsrc/xen/xen.git/builds/native
>> 
>> And executing:
>> 
>>   ➜  ../../configure
>
> Thanks for testing, but the patch series only focus on a subset of the
> repository, that is the hypervisor "xen.git/xen/". The rest of xen.git
> isn't ready for out-of-tree build unfortunately. A lot more work is
> needed.
>
>> In "build: adding out-of-tree support to the xen build" you describe the
>> Linux kernel style which works well where the config can be done after
>> the fact but I wonder if the configure approach is better suited to
>> something that needs a bunch of checks running. Is the configure script
>> pure autoconf? This should work out of the box IIRC.
>
> "xen.git/xen/" does use a build system similar to Linux's, we use
> Linux's Kconfig for example.

Ahh makes more sense in that context ;-)

> For the rest of the repository, it is indeed autoconf for the
> configuration phase. So yes running ./configure would be mostly ok, but
> it doesn't take care of Makefiles at the moment and I found one bug in
> our autoconf macros. Beyond that, our Makefiles aren't ready.
>
> xen.git isn't a single build system, they are several (at least one
> foreach of xen/ stubdom/ tools/)

I wonder if there is any millage in thinking about splitting
repositories and having them as subrepos of the main xen.git?

I can imagine building the core hypervisor as a standalone project is
something that is done a lot at least by developers. In a hypothetical
rust-vmm enabled world for example would you only need the hypervisor
itself if you had an alternate userspace to launch things?

>
> Cheers,

-- 
Alex Bennée