Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
On Sat, Oct 20, 2007 at 10:22:27AM -0700, Niels Provos wrote:
> After talking with Nick, I think the solution that makes the most
> sense is to build three different libraries:
>
> - libevent-core which contains only the event loop
> - libevent-extras which contains DNS, HTTP, etc.
> - libevent which contains everything for backwards compatibility
>
> That should make everyone happy.
Okay! I'll do this in trunk in the next couple of days, assuming that
nobody objects.
Another issue: We're apparently using the --revision and --version
arguments to libtool wrong. Our use of --revision means that binaries
built against one version of libevent need to be rebuilt to use the
next. Our current non-use f --version-info means that once we fix the
--revision problem, we'll give linkers the wrong idea about which
versions of libevent are which.
What we need to do in order to use --version-info correctly is
described here:
http://sourceware.org/autobook/autobook/autobook_91.html
Is this something that we're willing to do? If I understand the
documentation correctly, then practice, we'd have to keep 3 numbers:
"Current", "Revision", and "Age". We'd need to note, whenever we do a
new release: whether it adds new interfaces, and whether it breaks
binary compatibility, and then, by cases:
if (the interface changed) {
if (binary compatibility isn't broken)
increment "age";
Increment "current", set "revision" to 0.
} else {
increment "revision";
}
It's a little more bookkeeping, but I believe it would make us play
better with linkers and applications. For more background, see the
thread "Question: Library Naming."
yrs,
--
Nick Mathewson
pgpFaEybGoy1x.pgp
Description: PGP signature
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
After talking with Nick, I think the solution that makes the most sense is to build three different libraries: - libevent-core which contains only the event loop - libevent-extras which contains DNS, HTTP, etc. - libevent which contains everything for backwards compatibility That should make everyone happy. Niels. On 10/2/07, Chris Brody-GMail <[EMAIL PROTECTED]> wrote: > On 10/2/07, Nick Mathewson <[EMAIL PROTECTED]> wrote: > > On Tue, Oct 02, 2007 at 09:35:48AM +0200, Robert Iakobashvili wrote: > > [...] > > > libcurl has developed a good API for its integration with libevent. > > > libcurl project also maintains and develops a very good asynchronous DNS > > > client library, called c-ares (a clone of ares). > > > > > > Could it be a better path to concentrate the community efforts on > > > integration of c-ares and libcurl with libevent and to assist better > > > to applications? > > > > I would love somebody to get c-ares working right with libevent. I > > don't think this is a matter of "concentrating the community efforts", > > however: I think it's a matter of somebody stepping up to contribute > > the right patch to c-ares. > [...] > I am happy to take a look in my free time, despite a lack of > experience with libcurl & c-ares. I hope the HTTP & DNS parts of > libevent can be officially built separately, regardless about where > the source code is kept. > > Due to a lack of "official" RPM, my company is building libevent > ourselves, so I would like to try Christopher's patches to Makefile.am > & configure.in internally and report the results. > > I would like to suggest another idea, to automatically build both a > "full" libevent library and a set of separated libevent parts, until > the next major release. > > Chris > ___ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
