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.