Re: [XEN PATCH v7 49/51] build: adding out-of-tree support to the xen build

[Juergen Gross <jgross@xxxxxxxx>]

On 18.10.21 13:07, Jan Beulich wrote:
> On 18.10.2021 12:40, Juergen Gross wrote:
> > On 18.10.21 12:36, Jan Beulich wrote:
> > > On 18.10.2021 12:28, Juergen Gross wrote:
> > > > On 18.10.21 11:51, Anthony PERARD wrote:
> > > > > On Mon, Oct 18, 2021 at 11:02:20AM +0200, Jan Beulich wrote:
> > > > > > On 15.10.2021 18:58, Anthony PERARD wrote:
> > > > > > > I have to think about that. I've made some further progress in order to
> > > > > > > be able to build the Xen pvhshim without a link farm and notice that
> > > > > > > nearly every source file needs to use "$(srctree)/$(src)"
> > > > > > Oh, now I'm curious as to the why here. I thought use of $(srctree)
> > > > > > ought to be the exception.
> > > > > In Linux, the use of $(srctree) is indeed the exception. This is because
> > > > > we have VPATH=$(srctree), so when `make` look for a prerequisite or a
> > > > > target it will look first in the current directory and then in
> > > > > $(srctree). That works fine as long as the source tree only have sources
> > > > > and no built files.
> > > > >
> > > > > But if we want to be able to build the pv-shim without the linkfarm and
> > > > > thus using out-of-tree build, we are going to need the ability to build
> > > > > from a non-clean source tree. I don't think another way is possible.
> > > > Is there any reason (apart from historical ones) to build the hypervisor
> > > > in $(srctree)?
> > > >
> > > > I could see several advantages to build it in another directory as soon
> > > > as the build system has this capability:
> > > >
> > > > - possibility to have a simple build target for building multiple archs
> > > >      (assuming the cross-tools are available), leading to probably less
> > > >      problems with breaking the build of "the other" architecture we are
> > > >      normally not working with (and in future with e.g. Risc-V being added
> > > >      this will be even more important)
> > > >
> > > > - possibility to have a debug and a non-debug build in parallel (in fact
> > > >      at least at SUSE we are working around that by building those with an
> > > >      intermediate "make clean" for being able to package both variants)
> > > >
> > > > - make clean for the hypervisor part would be just a "rm -r"
> > > I fully agree, yet ...
> > >
> > > > Yes, this would require us (the developers) to maybe change some habits,
> > > > but I think this would be better than working around the issues by
> > > > adding $(srctree) all over the build system.
> > > ... developers' habits would only be my second concern here (and if that
> > > had been the only one, then I would not see this as a reason speaking
> > > against the change, but as said I've never been building from the root,
> > > and I've also been building sort of out-of-tree all the time). Yet while
> > > writing this reply I came to realize that my primary concern was wrong:
> > > People would not need to adjust their spec files (or alike), at least
> > > not as long as they consume only files living under dist/.
> > >
> > > So, Anthony - thoughts about making the default in-tree Xen build
> > > actually build into, say, build/xen/?
> > Or maybe even build-<arch>[-debug]/xen/?
> I'd be okay with build-<arch>, but things would become questionable imo
> when considering further elements recorded in .config: Where would you
> draw the line?
Okay, this is a valid question. What about an environment variable which
can be used to determine the build directory (or a suffix of the build
directory)?

This could be used to cover other use cases, too.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature