Re: Getting rid of (many) dynamic link creations in the xen build

["Jürgen Groß" <jgross@suse.com>]

On 16.10.20 08:58, Jan Beulich wrote:
> On 15.10.2020 12:41, Jürgen Groß wrote:
>> On 15.10.20 12:09, Jan Beulich wrote:
>>> On 15.10.2020 09:58, Jürgen Groß wrote:
>>>> - tools/include/xen/foreign -> tools/include/xen-foreign:
>>>>      Get rid of tools/include/xen-foreign and generate the headers directly
>>>>      in xen/include/public/foreign instead.
>>>
>>> Except that conceptually building in tools/ would better not alter
>>> the xen/ subtree in any way.
>>
>> I meant to generate the headers from the hypervisor build instead.
> 
> This would make the tools/ build dependent upon xen/ having got
> built first aiui, which I think we want to avoid.

Today we have a mechanism to build tools/include (i.e. setup the links)
from the main Makefile. The same rule could be used to create the needed
headers in xen/include/public/foreign.

> 
>>>> - tools/include/xen/lib/<arch>/* -> xen/include/xen/lib/<arch>/*:
>>>>      Move xen/include/xen/lib/<arch> to xen/include/tools/lib/<arch> and
>>>>      add "-Ixen/include/tools" to the CFLAGS of tools.
>>>
>>> Why not -Ixen/include/xen without any movement? Perhaps because
>>
>> This would open up most of the hypervisor private headers to be
>> easily includable by tools.
> 
> Without the xen/ prefix, yes. But if someone wants to violate the
> naming scheme to get at them, adding a suitable number of ../ will
> also work as soon as symlinks aren't being used, or symlinks of
> full directories are used instead of ones referencing individual
> files.

We'd need to be very careful regarding name collisions in this case
(there is e.g. xen/list.h and we have at least one list.h in a local
directory). I'm not sure we want to take that additional risk.


Juergen