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

[Jan Beulich <jbeulich@suse.com>]

On 21.12.2021 16:26, Jan Beulich wrote:
> On 25.11.2021 14:39, Anthony PERARD wrote:
>> Patch series available in this git branch:
>> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.build-system-xen-v8
>>
>> v8:
>>     Mostly rework of v7. With many patch already applied.
>>     Some detail changes that are spread through many patches:
>>     - `make cloc` recipe should now work throughout the series, update of it is
>>       done in 3 patches.
>>     - new patch "build: fix enforce unique symbols for recent clang version"
>>       to fix an issue with clang.
>>     - introducing $(srctree) and $(objtree) earlier
>>     - introducing $(srcdir) as shortcut for $(srctree)/$(src)
>>     - introduce usage of -iquote instead of -I in some cases
>>     More detail change log can be found in patches notes.
>>
>>     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.

Having looked at the RFC patches near the end of the series, I find the
need to convert from '#include "..."' to '#include <...>' particularly
problematic: Using "" for "local" files is common practice, and hence
even if you take care of the existing cases I'm afraid we'll be at
constant risk of re-introducing such an issue somewhere. And someone
hitting this issue may have a hard time figuring that it's simply the
wrong file which gets included somewhere. IOW I guess I'm now favoring
the "require clean source tree for out-of-tree builds" model.

Jan