Re: [Buildroot] [EXTERNAL] [PATCH v4 2/4] package/xen: add custom version support

"Weber \(US\), Matthew L via buildroot" <[email protected]> Mon, 3 Aug 2026 15:21:43 +0000
Newsgroups net.busybox.buildroot
Message-ID <BN0P110MB20672AF5339439D6D7AD3013F3D5A@BN0P110MB2067.NAMP110.PROD.OUTLOOK.COM>
Neal,

> -----Original Message-----
> From: buildroot <[email protected]> On Behalf Of Neal Frager via buildroot
> Sent: Monday, August 3, 2026 9:52 AM
> To: [email protected]
> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Weber (US), Matthew L <[email protected]>; Matthew Weber <[email protected]>; [email protected]; [email protected]; Wood (US), Brian J <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Neal Frager <[email protected]>
> Subject: [EXTERNAL] [Buildroot] [PATCH v4 2/4] package/xen: add custom version support
>
>  EXT email: be mindful of links/attachments.
>
>
>
>  Add the ability to configure specific Xen versions while leaving the default version unchanged to avoid breaking any builds already using Xen 4.21.1.

I think there is an edge case that if the user's custom tarball or GIT repo selects XEN_TOOLS and contains the qemu-xen folder with a cached set of files those won't be used.  We currently unconditionally do the following in xen.mk.

define XEN_INSTALL_QEMU_XEN_SRC
	rm -rf $(@D)/tools/qemu-xen
	cp -a $(QEMU_XEN_DIR) $(@D)/tools/qemu-xen
endef

I don't think this edge case is worth considering at this point and if someone runs into it, they could add a new check for existence of that folder and fail out.  Or determine a better option.

Regards,
Matt
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot