Daniel Veillard wrote:
On Sat, Mar 30, 2013 at 07:11:35PM +0000, Alex Bligh wrote:BTW the xml is generated so that should be discarded from the patch,That's strange. It appears in git and has a history. https://git.gnome.org/browse/libxml2/tree/doc/libxml2-api.xml How does one regenerate it (as the normal build process didn't)?Ah, well usually I do this only at release times, but it can be useful when developping a patch too, so have a look at doc/apibuild.py It is a large bit of rather ugly Python, but it scans the .h files, the .c files, and generate a formal API description of all exported entry points and structures: doc/libxml2-api.xml From there a number of other things are generated such as the online docs, checks for the exported symbol files, python bindings ... doc/ is been exported as the website for the project, so what you see online reflects the documentation for what is foudn in git, and what you see on your hard drive (if you installed the developments bits) is what corresponds to your released version. Those are non-standard practices of libxml2 development and I reused them into libxslt and libvirt :-)
Ok but for instance NEWS file is one of autogenerated documentation that is not updated .
Git repo show : ... |to the SVN at http://svn.gnome.org/viewvc/libxml2/trunk/ code base.Here is the list of public releases: 2.7.6: Oct 6 2009: .... |Next is that after buf api updates 'elf gcc hack' is not implemented (see attached file "0002-elfgcchack-for-buf-module.patch"). This update will change header - see attached "0003-elfgcchack.h-after-rebuild-in-doc.patch".
Another issue is that win32/libxml2.def.src is not updated. This impact makefile based windows builds - ref win32 directory.
Also another minor issue is that libxml-xzlib.html is not listed in distribution ( 0012-rebuild-docs-Makefile.am.patch) . May be is not reported if official source tarbal is build differently than make dist.
Off-topic: automake 13+ include improved macro to detect python.May be could be used instead custom one. Next part from configure script show defect on tested platform :
...# does not work as it produce a /usr/lib/python path instead of/usr/lib64/python
## PYTHON_SITE_PACKAGES=`$PYTHON -c "from distutils import sysconfig; print(sysconfig.get_python_lib())"`
... On my system I think that results is expected one:$ python -c 'from distutils import sysconfig; print(sysconfig.get_python_lib())'
/usr/lib64/python2.7/site-packagesI think that recent python updates require at least 2.7+ or 3.1+ (Capsule object).
Daniel
Roumen
Attachment:
0002-elfgcchack-for-buf-module.patch
Description: Text Data
Attachment:
0003-elfgcchack.h-after-rebuild-in-doc.patch
Description: Text Data
Attachment:
0012-rebuild-docs-Makefile.am.patch
Description: Text Data