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.