[xml] python bindings on windows

Hi all,

Since I could not find a binary distribution of
the python bindings on windows, I set out to
build it myself. Here is a report of my experience,
along with a few questions about the build process
and packaging of the python extensions.

I ran the following procedure 
successfully on a recent CVS checkout (post 2.4.26).

First, here are the changes I had to make.

1. Add a few missing exports to libxml2.def.src:


and libxslt.def.src


2. #include "config.h" does not work on Windows.

I'm not sure if this is Python's config.h or libxml's.
I commented it out (maybe it shoud be #ifdef'd) in
- gnome-xml/python/generator.py
- gnome-xml/python/libxml.c
- libxslt/python/generator.py
- libxslt/python/libxslt.c

3. To build using the MERGED_MODULES option, I had to copy
a few files from libxslt/python to libxml2/python. I don't know
the correct way to do that, or if there is an script
that does it. I did it manually.

4. Finally, I applied minor changes to setup.py to use 
the correct path for includes and libraries, as well as to link
with "libxml2" and "libxslt" instead of "xml2" and "xslt",
and remove "m" and "z" from the libs.

I tried to preserve the unix behaviour, and I can post
my changes if someone is interested.

Now, the packaging question.

I would like to use the nice python distutils feature
that creates a windows installer to make a binary distribution
containing both the python bindings and the libxml and libxslt
dlls. The question is where to install the dlls?

Putting them in %SYSTEMROOT%\system32 would probably create
many versioning headaches. A nice place that avoids all
versioning conflicts, is to put them 
in the same place as the libxml2mod.pyd and libxsltmod.pyd
(in python/lib/site-packages, that is). The problem, is that
you end up with the following files in the same place:
libxml2.py, libxml2.dll and libxml2mod.pyd (and the
same for xslt). 

Now when you try "import libxml2", unfortunately, python first 
tries to load libxml2.dll and fails since that one is not a python
extension. The solution I found is to create the following
directory structure in site-packages:


The only change necessary is then to write 
"from libxmlmods import libxml2mod"
instead of "import libxml2mod" in libxml2.py.
That change is fairly straightforward, and should not break any
existing code since (as I understand it) libxml2mod is normally 
not imported directly. 

I find that solution very convenient, because in one 
installer package, I can distribute the python bindings 
together with their private copy of the libxml dlls: 
easy to install and no risk of clashing with 
preinstalled versions.

If there is some interest for such an approach, 
I can post the installer somewhere, so you can give it a try.
What I would like to do also is discuss wether it
is worthwhile putting such a change in the main CVS,
or if I should maintain this way of packaging

Sorry for the long post. And thank you for these excellent tools.


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