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

[Juergen Gross <jgross@xxxxxxxx>]

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:
> > > On Thu, Oct 14, 2021 at 12:14:29PM +0200, Jan Beulich wrote:
> > > > On 24.08.2021 12:50, Anthony PERARD wrote:
> > > > > --- a/xen/Rules.mk
> > > > > +++ b/xen/Rules.mk
> > > > > @@ -38,7 +38,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
> > > > >                            $(foreach r,rel rel.ro,data.$(r).local)
> > > > >   
> > > > >   # The filename build.mk has precedence over Makefile
> > > > > -mk-dir := $(src)
> > > > > +mk-dir := $(srctree)/$(src)
> > > > >   include $(if $(wildcard 
> > > > > $(mk-dir)/build.mk),$(mk-dir)/build.mk,$(mk-dir)/Makefile)
> > > > Perhaps already when it was changed to $(src) the name has become
> > > > slightly misleading, at least imo: I would rather expect a variable
> > > > with this name to refer to the build dir/tree. Maybe "srcdir" or
> > > > even shorted "sd" right from the start? (Reaching here I can finally
> > > > see why having a shorthand is helpful.)
> > > 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"

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.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature