==> netbsd: In file included from ../listener.c:57:0:
==> netbsd: ../util-internal.h:58:0: warning: "__func__" redefined [enabled by default]
==> netbsd: #define __func__ EVENT____func__
==> netbsd: ^
==> netbsd: In file included from /usr/include/amd64/types.h:39:0,
==> netbsd: from /usr/include/sys/types.h:45,
==> netbsd: from ../listener.c:30:
==> netbsd: /usr/include/sys/cdefs.h:394:0: note: this is the location of the previous definition
==> netbsd: #define __func__ __PRETTY_FUNCTION__
Before, running make > /dev/null would result in status information cluttering
the error log. This changes it so that event_rpcgen.py prints status
information to stdout like the rest of the build tools.
The old code would use type_var_add() for its side-effect of expanding the
array, then leak the new object that was added to the array.
The new code adds a static function to handle the array resizing.
This makes evprc setup more extensible, and helps with Shuo Chen's
work on implementing Google protocol buffers rpc on top of Libevent 2
evrpc.
This patch breaks binary compatibility with previous versions of
Libevent, since it changes struct evrpc and the signature of
evrpc_register_generic(). Since all compliant code should be calling
evrpc_register_generic via EVRPC_REGISTER, it shouldn't break source
compatibility.
(Code by Shuo Chen; commit message by Nick)
Others may remain. I wasn't able to get gcc --std=c89 to build libevent
at all, so I don't know what compiler the original reporter is using here.
Note that this change requires us to disable the part of our rpc code
that uses variadic macros when using a non-gcc compiler. This is a
problem if we want our rpc api to be portable.
svn:r1231
Stop using deprecated autoconf code to set integer types; detect actual files to include more thoroughly. This should make us work on solaris 9 again. This should be a backport candidate, if it works. Also, make all libevent code use ev_uint32_t etc, rather than uint_32_t.
svn:r649
In ANSI C, int func() is a function with unspecified arguments, whereas int func(void) is a function that takes no arguments. Using int func() to mean a function with no arguments is a C++ism, so let's not use or generate it.
svn:r395
at integrating something really simple with HTTP. The interface is still
evolving as I start messing with it. Not all the interfaces are properly
exported yet.
I am also trying to figure out how to intelligently hide the details about
the different structures from users, so that that things can be changed
around later.
svn:r196