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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.10.2020 09:25, Jürgen Groß wrote:
> 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.

Oh, indeed.

>>>>> - 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.

Well, header in local dirs aren't a big problem - they get included
via #include "xyz.h" anyway. But I see your point, and this imo is an
argument to stick to symlinks, as this avoids unnecessary dir levels
and allows to be as selective as we want/need to be.

Jan