Re: [Libevent-users] Libevent 2.0.1-alpha is released
On Fri, May 22, 2009 at 08:29:01PM +0100, James Mansion wrote: > Nick Mathewson wrote: > >"A private type"? What kind of thing do you mean here? > > > The struct just has a couple of integer fields and won't vary by > platform, so > having a libevent struct that can be converted is probably easy enough. > > All we really need is something that represents a time with a big enough > range and a decent resolution - I don't think a 'struct timeval' really > needs > to be in the interface. Replacing timeval is probably a non-starter. It would be nice to remote the header dependency on Windows, but in order to remove struct timeval from all Libevent interfaces, we'd have to break backward API compatibility with all existing Libevent applications, which would probably not make us any friends. > >OTHER QUESTIONS: > > > >Q1: > > > >It sounds like you're winding up with project files that are better > >than the ones we have. Is that so? Should we ship yours instead? > > > > > All I did was open in VS2008 Express and let it convert them. Well, and > a couple of tweaks to the include paths etc. I got the impression that > there > was some surgery going on for the directory structures etc. > >(I'd try to reproduce your changes, but I always screw up Visual > >Studio stuff whenever I touch it, and wind up making changes only to > >the debug build, or adding absolute paths by mistake, or stuff like > >that.) > > > Well, I do too. I tend to use the IDE for debugging and development > only. Its why I'd > suggest looking at cmake or something else. Yeah; I may have acted too dismissively to cmake initially. I think it would be a mistake to _replace_ our autotools stuff with cmake in a 2.0.x timeframe, but if cmake is the best way to produce project files that make VS people happy, I'd be fine using cmake for that. [...] > If you are more comfortable with make, why not just use nmake? Its not > as if this is a > very complex project structure. Sure, nmake would be fine too. I'd love to include a good nmake file if anybody writes one. -- Nick ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
Nick Mathewson wrote: [...] > Yeah; I may have acted too dismissively to cmake initially. I think > it would be a mistake to _replace_ our autotools stuff with cmake in a > 2.0.x timeframe, but if cmake is the best way to produce project files > that make VS people happy, I'd be fine using cmake for that. > > [...] >> If you are more comfortable with make, why not just use nmake? Its not >> as if this is a >> very complex project structure. > > Sure, nmake would be fine too. I'd love to include a good nmake file > if anybody writes one. For my work on MySQL Proxy (which uses libevent, sure) I use both: * autotools for all the unixes * cmake for windows It is sometimes a pain as they are not always in sync, but both systems have their unique features and are important, like autotools "make distcheck" feature which does everything to verify that a build is good. I usually use cmake for the development phase (it is faster to build with cmake) and use automake and friends for the packaging and distribution. cheers, Jan -- jan: "Gee, Brain^WEric, what'd you wanna do tonight?" eric: Same thing we do everynight: Take over the HelloWorld! ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Libevent 2.0.1-alpha is released
Nick Mathewson wrote: Replacing timeval is probably a non-starter. It would be nice to remote the header dependency on Windows, but in order to remove struct timeval from all Libevent interfaces, we'd have to break backward API compatibility with all existing Libevent applications, which would probably not make us any friends. OK well I've been playing with replacing the production of the event-config.h file with waf, and I think the problem lies in inconsistent use of Windows headers. That type really needs to come from winsock2.h, and ideally ws2tcpip.h should be used to pull in the windows headers needed - there are some places where we just get windows.h and that just uses winsock.h which will cause trouble. Never mind. Yeah; I may have acted too dismissively to cmake initially. I think it would be a mistake to _replace_ our autotools stuff with cmake in a 2.0.x timeframe, but if cmake is the best way to produce project files that make VS people happy, I'd be fine using cmake for that. I'm actually happier with waf at the moment, but I realise that cmake has reasonable traction at the moment with some big projects using it. James ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
