Re: PATCH: Cleanup generator & force build fail on missing APIs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]