On Mon, Feb 19, 2018 at 08:10:49PM +0800, Andy Green <a...@warmcat.com> wrote:
> Since libevent uses the preprocessor, it gets the final say; in other words
> since it defines EV_READ etc to a different value, building some software
> that can operate with both libevent and libev results in nothing working or
> not even build completing if you include the libevent bits first.

Most software choses the event model at compile time, where this causes
no issue. If you want to support both at runtime, just put the libev code
in one source file and the libevent code in another, and this problem is
solved.

> This is basically an interoperability problem between libevent and libev, or
> libev and libevent, it would be great if there is something that can be done
> to allow the happy coexistence merry-go-round to spin once more for these
> two libraries.

It's not really a problem in practise, and certainly not an obstacle for
users of these libraries.

> for libevent, but I learned there the situation is more complex than I
> expected, with libev providing some libevent compatibility by design.

Yes, libev offers the libevent (v1) api as well.

> For downstream maintainers like me whose users wish to be able to use both,

What you described doesn't seem to be an actual problem - can you give a
more detailed explanation, maybe with an example, of what you want to do
and can't?

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schm...@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev

Reply via email to