2010/5/31 Brodie Thiesfield <brofie...@jellycan.com>: > Hi all, > > I've updated the cmake build harness that Alexey Ozeritsky supplied, and > I've updated it to build the latest source both released and in git. > I've tested the build on both Windows (VC 2008) and Linux (gcc 4.4) and > apart from warnings it builds. > > It now does full detection of header files, functions, symbols, etc on > all platforms. It also generates the RPC files from the source on > Windows (requires python to be installed). The regress test harness > runs, but there are a number of failures on both Windows and Linux. > > This build harness is still a work in progress, but it shows promise. By > using cmake, the Visual Studio 2008 projects are generated automatically > (or makefiles on Linux).
Hi, Brodie, and sorry for the delay. :/ This looks like something worth considering for Libevent 2.1. (Libevent 2.0.x is in feature-freeze.) I think the sensible first target here is to see if we use this just for generating visual studio stuff only, and continue to ship autotools for unix-like systems. Replacing autotools on unix/mac/mingw would be a harder sell for me because, as it stands, it works okay, and it does lots of stuff that your cmake script doesn't. For example, there are plenty of --enable-XYZ flags your script doesn't support, and there are some tricky cases that I don't see where it considers. (For example, how you need magic options in order to make some libcs build thread-safe code.) This is not to say "never", but rather to say "I fear regressions from replacing autotools on the platforms where it currently works, but I like the idea of generating project files that Visual Studio users will find worthwhile, since apparently none of them agree with me that Makefile.nmake is better than project files." ;) > This is also some changes required to the bench_cascade.c file in order > to have it compile on Windows. It looks like these already happened in git master somewhere along the line? I'm not seeing a difference between your bench_cascade.c and the one in git head. > Question: > Since all of the header files are now in include/event2/. wouldn't it be > better if the event-config.h header file was also generated into that > directory so that all libevent headers are always loaded from > <event2/foo.h>? That sounds like a good idea. I've got a git branch on my github repo that tries to do this; if nobody objects, I'll merge it soon. (git://github.com/nmathewson/Libevent.git ; branch is move_eventconfig_h.) many thanks, -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
