[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 21.12.2021 16:26, Jan Beulich wrote: > 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. Having looked at the RFC patches near the end of the series, I find the need to convert from '#include "..."' to '#include <...>' particularly problematic: Using "" for "local" files is common practice, and hence even if you take care of the existing cases I'm afraid we'll be at constant risk of re-introducing such an issue somewhere. And someone hitting this issue may have a hard time figuring that it's simply the wrong file which gets included somewhere. IOW I guess I'm now favoring the "require clean source tree for out-of-tree builds" model. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |