On Tue, May 12, 2009 at 12:09:28PM +0200, Malek Hadj-Ali <[email protected]> wrote:
> 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).

Actually, almost every OS has LFS support in the default compilation
environment, except most gnu/linux distros, which insist on no lfs support by
default.

The reason for that escapes me.

Now, even with lfs support you cannot be sure that ev_statdata is the ame
thing as your struct fstat.

Now, if there were a way to determine lfs support somewhat reliably in
the header file then libev could at least give you the same ev_statdata
structure regardless of compilation flags, but afaics, the LFS doesn't
give you enough hits to see whether it is enabled or not, and how to get
at the 64 bit struct stat, if it exists.

Of course, the problem would go away if the default on gnu/linux would be
sensible. (Or maybe one could just hardcode stat64 on gnu/linux systems,
but it is too late for that).

> > 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).

Debian started a small war because EV (the perl module) embedded libev,
btw. :)

The problem with not embedding, btw., is that this only works for dynamic
linking. When doing static linking, this "use same libev from multiple
independent software modules" fails. This cna be quite dangerous.

In fact, if you expose the C api of your embedded lib (EV does that), then
it is possible to integrate C and python code seamlessly, without this
danger.

(So, there is no obviously best way)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      [email protected]
      -=====/_/_//_/\_,_/ /_/\_\

_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

Reply via email to