On February 19, 2018 10:06:04 PM GMT+08:00, Marc Lehmann <schm...@schmorp.de> 
>On Mon, Feb 19, 2018 at 08:10:49PM +0800, Andy Green <a...@warmcat.com>
>> Since libevent uses the preprocessor, it gets the final say; in other
>> since it defines EV_READ etc to a different value, building some
>> 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
>in one source file and the libevent code in another, and this problem

You sound confident about that, but actually having implemented it, you have 
not considered that the structures composing event lib state (handles, loop 
objects etc) must be defined in one place with types available for all event 
libs simultaneously.

>> 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
>> two libraries.
>It's not really a problem in practise, and certainly not an obstacle
>users of these libraries.

*waves hand*  hellooo!

>> for libevent, but I learned there the situation is more complex than
>> 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
>What you described doesn't seem to be an actual problem - can you give
>more detailed explanation, maybe with an example, of what you want to
>and can't?

I explained the scenario in my other reply.


libev mailing list

Reply via email to