Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-06-30 at 15:36 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete 
> build-i386-libvirt"):
> > On Mon, 2014-06-30 at 15:13 +0100, Ian Jackson wrote:
> > > Perhaps we can avoid this by having the libvirt builds #define
> > > LIBXL_API_VERSION but only some of the time.  As a configure option
> > > perhaps.  (The configure option would specify not the version to use,
> > > but rather just that VERSION ought to be defined rather than not.)
> > 
> > We could probably arrange for this ourselves in the harness, using
> > whatever CFLAGS-appending scheme the libvirt build system supports.
> 
> Then we would have to choose the version which would be wrong.  The
> actual version to define or not ought to be along with the libvirt
> code in its git reepo.
> 
> > However we currently insist that LIBXL_API_VERSION is one of a known
> > bunch of values if it is set, so defining it without a specific value
> > won't currently work.
> 
> That's not what I mean.
> 
> I mean that libvirt would offer a configure option whose meaning would
> be "please define LIBXL_API_VERSION to whatever the latest version is
> that you support".

OIC, yes I suppose that might work. I have a feeling folks on the
libvirt side might not be so keen though. Copying Jim.

Oh wait. If libvirt supports up to e.g. Xen 4.4 today then this option
would cause it to #define LIBXL_API_VERSION to that. But Xen 4.2 and 4.3
libxl wouldn't know what to do with it and would bail out.

We could deploy this flag only on the xen-unstable flights on the
assumption that this is the only place where the libxl API ought to be
changing.

> > Another wrinkle is that like SONAMES we only currently bump
> > LIBXL_API_VERSION once per release cycle (if at all).
> 
> That would be easy to do differently.  We don't make changes like this
> all that often and they already involve a lot of palaver.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel