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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list