Daniel Veillard wrote:
On Thu, Nov 29, 2007 at 04:58:42PM +0000, Richard W.M. Jones wrote:
> Cygwin likes to name DLLs as cyg<name>.dll.
>
> This is very unhelpful for Python loadable modules because the init
> function name will be wrong and because it requires a change to the
> 'libvirt.py' file to load the right module name (import libvirtmod ->
> import cygvirtmod).
hum, I think it would also require a change to the python C file
to rename the entry point too, otherwise a simple
try:
import libvirtmod
except:
import cygvirtmod
might have done it.
> In this patch I've added a post-install hook to make a symlink so that
> Python finds libvirtmod.dll and all is happy.
I must admit I'm wondering a bit about ln -s reliability in a Windows
environment ... maybe the above try:/except: plus a change at the end of
python/libvir.c adding
'ln -s' relies on Cygwin, which fakes it by writing a file called
'libvirtmod.dll.lnk' (or somesuch).
So in some sense we require Cygwin, but of course all of this code needs
Cygwin to function.
Because this is Python the situation is arguably a little bit different.
There are essentially two versions of Python for Windows -- one is a
native port (compiled, presumably, with Visual C++), and the other is
the Cygwin port which is the one that I'm using now.
In theory I suppose a Cygwin-compiled Python module (*.dll) could be
loaded by the native Python. It wouldn't work for us though because
libvirtmod.dll requires cygvirt-0.dll which fundamentally requires
Cygwin. We'd have to do a native version of libvirt as well, which
involves lots of invasive changes.
#ifdef CYGWIN
void
initcygvirtmod(void)
{
initlibvirtmod();
}
#endif
might be a bit more reliable,
Either would work -- whichever you feel happier with.
Rich.
--
Emerging Technologies, Red Hat -
http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903