On Mon, Jan 21, 2008 at 09:12:12AM -0500, Daniel Veillard wrote: > On Mon, Jan 21, 2008 at 02:02:28PM +0000, Daniel P. Berrange wrote: > > On Mon, Jan 21, 2008 at 04:14:15AM -0500, Daniel Veillard wrote: > > > 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. > > > > Never fear - this is exactly the sort of problem the nightly autobuild > > is intended to catch - it'll fail the night after commit and send an > > email alert so we can fix it the very next day - hopefully long before > > release. > > okay but still asynchronous :-) > Since we don't often extend the public API you're probably right that it's > sufficient. Ok, comitted this. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list