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

[Jürgen Groß <jgross@xxxxxxxx>]

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