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: >>>> 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"
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/? Jan
