Re: [Xen-devel] [libvirt] [PATCH v2 4/4] libxl: Add a test suite for libxl option generator

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-06-17 at 12:40 -0600, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Mon, 2014-06-16 at 17:11 -0600, Jim Fehlig wrote:
> >   
> >>> This function exists in Xen 4.2 as well, in libxl.h.
> >>>   
> >>>       
> >> Any ideas on how to handle this?  I'm not aware of an existing macro to
> >> check for func 'foo' defined in header 'bar'.  Is writing a custom macro
> >> along these lines a good solution?  A bad solution I tried was hacking
> >> the test to check libxl version via libxl_get_version_info(), but that
> >> API does not work if not running Xen.
> >>     
> >
> > Given that it exists in everything from 4.2 onwards why do you need to
> > check for it?
> >   
> 
> Hrm, right.  I had the half-brained idea to use this to solve the
> failures I saw when testing this series against Xen 4.2
> 
> https://www.redhat.com/archives/libvir-list/2014-June/msg00170.html
> 
> I think the solution to that specific problem is to use Xen 4.2 config
> as the baseline.  But it got me thinking about the general problem you
> mentioned near the end of this mail
> 
> https://www.redhat.com/archives/libvir-list/2014-June/msg00032.html
> 
> With virJSONStringCompare in 1/1, Daniel provides a way to handle
> existence of new fields showing up in the json.  But what if I want to
> write a test where the expected data is not supported on earlier
> versions?   E.g. how would I add a test to check conversion of '<tpm
> ...>' to 'vtpms: [ ]' and expect that to work when running 'make check'
> against a 4.2 libxl where vtpms were not yet supported?  I suppose each
> such test would have to probe for the feature it checks and skip if not
> found.

Right. You'd probably want to gate such a test case on the corresponding
LIBXL_HAVE_XXX #define from libxl.h.

Ian.


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