ANN: Pyev 0.4.0-3.53

[common at gmx.ch]

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
> "common at gmx.ch" <common at gmx.ch> 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