[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH v8 00/47] xen: Build system improvements, now with out-of-tree build!
On 25.11.2021 14:39, Anthony PERARD wrote: > Patch series available in this git branch: > https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git > br.build-system-xen-v8 > > v8: > Mostly rework of v7. With many patch already applied. > Some detail changes that are spread through many patches: > - `make cloc` recipe should now work throughout the series, update of it > is > done in 3 patches. > - new patch "build: fix enforce unique symbols for recent clang version" > to fix an issue with clang. > - introducing $(srctree) and $(objtree) earlier > - introducing $(srcdir) as shortcut for $(srctree)/$(src) > - introduce usage of -iquote instead of -I in some cases > More detail change log can be found in patches notes. > > Also this v8 present a work-in-progress of the ability to do out-of-tree > build without setting VPATH. This is presented as an alternative to force > use of out-of-tree build. As the last patch show, it allows to build the > xen-shim without the linkfarm and we don't need to make any other changes > to any thing that build xen (osstest, distribution packages, xen.git, ..., > and developers finger macros). The patches are only there as WIP / RFC as > they were some concern about the usefulness and extra changes needed. > We can decide whether those changes are good or if this is too much and we > should force out-of-tree build for the hypervisor. I'm afraid I'm of two minds here. I don't think we want to force people to do out-of-tree builds, but I also dislike the idea of mixing in-tree and out-of-tree builds. Yet reading the above I understand that the shim build would conflict with an in-tree build because certain files would be picked (the shim build being an out-of-tree one) from the (dirtied) source tree, rather than the shim's build tree. Perhaps the extra path prefixes that I commented upon in an individual patch are then indeed the least bad route to take. There's one compromise which comes to mind, but which may also not be liked: We could simply fail out-of-tree builds when the source tree is dirty. Then people wanting the shim built would need to use out-of-tree builds also for the "main" hypervisor, but people suppressing the shim build anyway (or doing it separately, e.g. using a non-default .config) could continue to do in-tree builds. The one puzzle piece I'm lacking so far (perhaps simply because of having overlooked where it is) is how, for a full-build-of-everything, one would control where the xen/ part of the build would go _outside_ of the source (sub-)tree. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |