[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[Libevent-users] Re: cmake build harness



2010/5/31 Brodie Thiesfield <brofield2@xxxxxxxxxxxx>:
> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.