Malek Hadj-Ali wrote:
Hi,
First of all, let me apologize for the delay (real life has been a
little bit of a struggle lately, leaving me little or no free time for
pyev).
np
On Thu, 30 Apr 2009 19:56:14 +0200
"[email protected]" <[email protected]> wrote:
Pyev (http://code.google.com/p/pyev/) is a python extension wrapper
around libev.
As I had issues compiling/installing it ... I took some
countermeasures.
As I doubt its usefull to ship the binding with libev itself, I
decided to make it use a local libev installation.
I can't really agree on this. You see, libev api evolves and pyev tries
to follow it, so it makes sense to ship pyev with a matching libev
version (of course there's always a better approach, but I'll stick
with the easiest for the time being).
For libev, might be usefull to provide a way to determine the version &
features of the library, create ev.h from ev.h.in and set version number
& lfs flags.
So one can make use of them when using the library.
Usually the soname version string can be used to let glibc automatically
determine the compatibility of linked libraries.
http://sources.redhat.com/autobook/autobook/autobook_91.html#SEC91
I'm not sure if libev uses soname correctly though.
Oh yeah (almost forgot this one), and I have to embed libev to have
large file support in ev_stat watchers (python being mostly built
with LFS, see http://lists.schmorp.de/pipermail/libev/2008q1/000232.html
and http://lists.schmorp.de/pipermail/libev/2008q2/000381.html).
Did not use stat watchers, so I missed this one.
But for LFS, python uses lfs if sizeof(off_t) > sizeof(long) &&
exists(long long).
http://docs.python.org/library/posix.html
If there was a way to determine whether libev was build with lfs support
(as mentioned before) , one could simply ifdef the stat bindings.
I'd really appreciate if you would include the autoconf way to build it
as an alternative approach, as it prevents having multiple versions of
the same library installed.
Renaming the autoconf setup.py.in to autobuild.py.in, making it work,
and keep the shipped setup.py for those who want to.
The code to detect python 3.1 did not work with python 3.1a+ as the
version numbers are strings instead of ints.
Yeah. Pyev 0.4.0-3.53 was released on 03/12. On 03/26 platform.py
was changed (see http://svn.python.org/view?view=rev&revision=70628 and
http://bugs.python.org/issue5561), that's the price to pay for working
with an alpha release :-).
This is going to be fixed in the next release.
Is this the only compiling/installing issue you had?
No, it did not work at all.
python setup.py build
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
......
src/pyev.c:2811: warning: passing argument 2 of
‘PyErr_SetFromErrnoWithFilename’ discards qualifiers from pointer target
type
src/pyev.c: At top level:
src/pyev.c:4136: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘pyev_module’
src/pyev.c: In function ‘PyInit_pyev’:
src/pyev.c:4184: warning: ‘return’ with a value, in function returning void
As I link pyev.c with -lev I changed pyev.c to include ev.h instead of
ev.c, and it did the job.
A real great feature:
if you embed python into your libev powered application, you can use
these bindings to insert watchers into your applications
ev_default_loop from python, great work!
That is a great feature, and I'll keep that in mind for another project
that I have going, but for now I think I'm gonna stick with the more
traditional way of distributing python extension modules (that is one
that only requires a 'sudo python3 setup.py install' and you should be
done).
I guess this _feature_ only works when using the same libev version for
python as for the application, if struct layouts change.
Installing a seperate version of libev does not benefit here.
Nevertheless, pyev is a great work,
Markus
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
