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
