On 18.10.2021 13:20, Juergen Gross wrote: > 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)?
That would be fine with me, but as said I'm not building from the root dir anyway, so people affected by a possible change here may be more qualified to give input. Otoh if people need to adjust their stuff anyway, they can as well switch to an out-of-tree Xen build right away. And anyone building in-tree won't expect to be able to build multiple flavors in parallel. Jan
