On Tue, Jun 17, 2014 at 12:40:30PM -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.
My last approach was to allow the JSON comparator to skip certain
types of missing data but I don't think that's sufficiently flexible
anymore. I'm thinking instead, that we could maintain a set of
context paths which designate things that are new in each version,
which would indicate things that should be skipped with old versions.
So we with 4.3, we'd list
/c_info/driver_domain
/c_info/pvh
and any other newly added fields. Then when running the test on 4.2
if the expected XML contained either of those paths, we'd skip them
when comparing against the actual JSON.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|