On Wed, Nov 30, 2005 at 03:15:19PM -0800, Banginwar, Rajesh wrote: > Hi Daniel, > Little background first. When we develop LSB specification, we > try to divide specification for a given library into multiple sections, > each one representing part of library functionality. The same sections > then map to corresponding header supplied by LSB build environment. > > In case of libxml2, we were trying to do that based on the headers, each > one representing the functionality chunk. But while analyzing the > headers we are coming across multiple include loops. E.g. Tree.h is > included in parser.h and parser.h gets included in tree.h through some > include chain (xmlmemory, globals, sax2, parser.h). > > How do you suggest we untangle this so that the specification will look > better organized? One option will be to create aggregated includes, > reducing the no. of total include files.
Each header has a relatively clear purpose, it is written in the top comment and used to label the docs descriptions, e.g. tree.h is http://xmlsoft.org/html/libxml-lib.html tree: interfaces for tree manipulation http://xmlsoft.org/html/libxml-tree.html this module describes the structures found in an tree resulting from an XML or HTML parsing, as well as the API provided for various processing on that tree The fact that the headers requires each-other is related to technical issues with the C language and an historical constraints, I can't break application code which for example include just tree.h and call the parser nonetheless. I don't see why you mix the semantic of the headers with the way they end up including each other, the former is what you should care about, the latter is only of importance for the compiler and me. The semantic is untangled, in my opinion you have nothing to change to the headers themselves, the inclusion process itself is IMHO not what you should focuse on. If you modify the headers, this won't be libxml2 API it will be the LSB API and you will garantee its API, not me, I still call this a fork with all benefits and duties (change of code outside of the normal review process and without an associated upstream CVS commit with a subsequent public release is a fork, no matter the reason or who did it, evolution will be separate and I won't take this in consideration for the evolution of this project.) Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
