[Libvir] PATCH: 1/7 Split up the public header files

[Daniel Veillard]

On Wed, Oct 31, 2007 at 03:20:00PM +0000, Daniel P. Berrange wrote:
> On Wed, Oct 31, 2007 at 09:53:07AM -0400, Daniel Veillard wrote:
> > On Mon, Oct 29, 2007 at 03:56:18AM +0000, Daniel P. Berrange wrote:
> > > This patch splits up the libvirt.h file into multiple pieces. The big header
> > > file was getting rather long & hard to follow, with API calls for domains and
> > > networks all mixed together, and macros & typedefs & methods all mixed up.
> > > Adding another 25 APIs for storage won't improve this. So this splits up the 
> > > header into
> > > 
> > >    libvirt/connection.h    - connection related API calls & objects
> > >    libvirt/node.h          - host node information APIs  & objects
> > >    libvirt/domain.h        - hypervisor/domain API calls & objects
> > >    libvirt/network.h       - virtual networking API calls & objects
> > > 
> > > The original libvirt.h, now simply #include's all four of these files. The
> > > header files aren't intended to be included directly - apps carry on just
> > > using the main header file.
> > 
> >   The main impact is not covered by this patch, it's the documentation
> > generation, which also mean that on the web site the doc page for libvirt 
> > would become nearly empty and 4 new pages would be added. 
> >   I'm not against the change (though it will break all previous reference
> > to documentation functions embedded in list archives) but the documentation
> > impact seems to not have been considered and it's not neglectible, really.
> 
> Hmm, yes I forgot about the docs - it will have an impact there. One could
> argue though that the impact will be positive, since it'll split the docs
> into more managable chunks each page dealing with a specific class of APIs.

  I'm not against, we just need to check all cross references :-\

> In any case, this patch doesn't really block any of the storage work - its
> just something I tried out. We can easily stay with existing scheme and
> reconsider it another time.

  let's just make it a separate kind of change and track it on its own,
I may give it some testing ...

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/