On Sun, Jan 20, 2008 at 05:29:06PM +0000, Daniel P. Berrange wrote:
> The python generator will happily ignore functions it can't handle and
> pretend everything completed without error. This leads to the situation
> where we add new APis to C library and no one ever notices that they
> are missing from the python until months later. This requires that my
> previous patch be applied first to implement the missing APIs we already
> have :-)
>
> This patch causes the generator to return a non-zero exit status if there
> are any APIs marked as FAILED. It will also explicitly print out their
> names so its clear what is missing. In doing this I added a bunch more
> functions to the skip list - ones that we already manually wrote.
>
> It also removes the manually written virCloseConnect/virDomainFree/
> virNetworkFree C code, since the generated code is just fine.
>
> Finally, it makes all manually written C functions static for consistency
Okay, the default behaviour prints the number of functions which failed
(and the number skipped) but now that we have full coverage, yes this is
a good thing to do. Note however that you're likely to still see the problem
of late discovery of missing bindings because:
- people submitting patches are likely to just run 'make'
- people applying it will do the same.
- only on 'make rebuild' in docs or when preparing the release
will we hit the docs/libvirt-api.xml , leading to the subsequent
error on a missing part.
- and I'm afraid I will be the one hitting them ... at time of release
i.e. at the worse moment with a make exiting on an error.
So okay to fail, but only if 'make' leads to a failure after modifying the
API headers, which probably means changing docs/Makefile.am to systematically
rebuild when libvirt.h (or .h.in since libvirt.h is autogenerated ?). Or some
other mechanism which somehow force people changing the API to rebuild the
XML and the bindings.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list