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

[Anthony PERARD <anthony.perard@citrix.com>]

On Tue, Dec 21, 2021 at 04:26:48PM +0100, Jan Beulich wrote:
> On 25.11.2021 14:39, Anthony PERARD wrote:
> >     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.

To me, the problem is with a few build artefact and configuration: the
".config" file that osstest write and edit, and the final location of
the "xen*" artefacts. Having something or someone wanting to edit
".config" breaks out-of-tree build. Otherwise, we could have forced
out-of-tree build like libvirt or qemu are doing.

> 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

This isn't a compromise, it is already implemented in "build: adding
out-of-tree support to the xen build". I revert this in patch "RFC,
no-VPATH: remove check for clean source tree for 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.

I guess that's not really an issue. It would be easy to run `make -C
xen-build -f ../xen/Makefile` (or `make -C xen O=../xen-build`, or even
`make -C xen O=build` would be fine too). With maybe a make variable to
let someone specify a different output tree.

For a full-build-of-everything, we can easily do out-of-tree build. The
full-install-of-everything can pick the build artefact from the new
place. The issue is when someone want that and edit ".config" of the
hypervisor, as adding the file will stop out-of-tree build, so pv shim
will not be able to use out-of-tree build.


But maybe going with mixing in-tree and out-of-tree build is going to be
too complicated. The hard part is for the build system to differentiate
between source file and generated source file, so that might break from
time to time. So maybe avoiding mixing and thus breaking build of some
users might be better and more reliable in the long term.

Cheers,

-- 
Anthony PERARD