[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.