Nick Mathewson wrote:
Good morning, evening, night, or afternoon!
The first alpha release in the long-promised Libevent 2.0 series
is finally out. You can download Libevent 2.0.1-alpha from
http://monkey.org/~provos/libevent-2.0.1-alpha.tar.gz
I have a number of patches designed to make the build on Win32 smoother.
I have the regress application building, although it does not run reliably.
The biggest changes are in the rpcgen program - most of the others are
minor.
Where should I send the patches?
I have a waf script that automates building the whole lot including
doing the config
stage if anyone is interested. Its not finalised (and I have yet to
make it work on
UNIX) but it may help dev without fiddling with msdev projects all the time.
The result fails the same way as the msdev build when a debug build is used,
and fails in other ways when an optimised build is done.
What is the expectation for regress.exe --no-fork on Windows? At the moment
it fails in test_edgetriggered because the 'fd' passed to write isn't
appropriate.
I can't help feeling that the attempt to use raw UNIX-style APIs and fd
abstraction
on Windows is likely to be fraught - its easy enough to create an
abstraction that
works OK, but doing so using the raw UNIX abstractions seems to me likely to
end up fighting the differences between sockets, file handles, and fd as
emulated by
C runtime on Windows.
It may be possible to bully it to work eventually, but its going to be
very messy.
Is it really so unpalatable to break the API with the major version change?
James
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users