Message ID | 20200823093519.18386-1-jgross@suse.com (mailing list archive) |
---|---|
Headers | show |
Series | tools: move most libraries into tools/libs | expand |
I have no objections. For the OCaml part in particular I previously said that I believe that it would benefit from either be maintained outside the tree (which requires a clean interface) or moving it to use Dune for its build (triggered by the current make build). Any cleanup that is helping here is welcome.
--
Acked-by: Christian Lindig <christian.lindig@citrix.com>??
On Sun, Aug 23, 2020 at 11:34:41AM +0200, Juergen Gross wrote: > Move most remaining libraries under tools/libs, including libxenctrl > and libxl. This is resulting in a lot of cleanup work regarding > building libs and restructuring of the tools directory. > One thing to point out is that libs was originally only supposed to be the home for _stable_ libraries. I have no objection to turning it into the home for all libraries though. I think this series is definitely an improvement over the status quo. > After this huge cleanup all dependencies between libraries are defined > in a single rather small file tools/libs/uselibs.mk, which is used to > create the needed make variables and to control the stubdom build > dependencies as well. > > Another bonus of the rework is the automation of setting the versions > of unstable libraries. This removes the need to bump those versions > manually for each Xen release. > > libfsimage is not moved by this series, as IMO there are some open > questions: > - should it really be unstable? > - is the support of adding external fs-support used in practice, i.e. > shouldn't the fs-specific sub-libraries be just included into > libfsimage instead of being loaded dynamically? My impression is that nowadays it is only consumed by pygrub, so it wouldn't really make a difference if we make it stable or not. It surely has not been changed for years though. Not entirely sure why it is designed to load dynamically different modules either. I don't have an opinion on this one way or another. I think your energy will have better ROI if you spend it somewhere else than trying to figure out definitive answers to these two questions. Wei.
On 27.08.20 13:07, Wei Liu wrote: > On Sun, Aug 23, 2020 at 11:34:41AM +0200, Juergen Gross wrote: >> Move most remaining libraries under tools/libs, including libxenctrl >> and libxl. This is resulting in a lot of cleanup work regarding >> building libs and restructuring of the tools directory. >> > > One thing to point out is that libs was originally only supposed to be > the home for _stable_ libraries. > > I have no objection to turning it into the home for all libraries > though. I think this series is definitely an improvement over the status > quo. > >> After this huge cleanup all dependencies between libraries are defined >> in a single rather small file tools/libs/uselibs.mk, which is used to >> create the needed make variables and to control the stubdom build >> dependencies as well. >> >> Another bonus of the rework is the automation of setting the versions >> of unstable libraries. This removes the need to bump those versions >> manually for each Xen release. >> >> libfsimage is not moved by this series, as IMO there are some open >> questions: >> - should it really be unstable? >> - is the support of adding external fs-support used in practice, i.e. >> shouldn't the fs-specific sub-libraries be just included into >> libfsimage instead of being loaded dynamically? > > My impression is that nowadays it is only consumed by pygrub, so it > wouldn't really make a difference if we make it stable or not. It surely > has not been changed for years though. Making it stable would have the advantage not having to bump the lib versions for each release (note that this is the last library left for which that is still necessary after this series). > Not entirely sure why it is designed to load dynamically different > modules either. I don't have an opinion on this one way or another. I have the vague feeling this might be related to the (IMO now very questionable) support of Solaris, as it was introduced by a Sun employee. > > I think your energy will have better ROI if you spend it somewhere else > than trying to figure out definitive answers to these two questions. :-) Juergen