William A. Rowe, Jr. wrote:
Justin Erenkrantz wrote:
On Fri, Jan 2, 2009 at 3:57 PM, William A. Rowe, Jr.
<[email protected]> wrote:
I don't know that we have any active interest in 2.0.0 at this moment,
Since I guess trunk is now 2.0.0, here's what I'd like to see:
1. fold in apr-util
+1, with the dso approach, it is not so harmful for apps to link to it,
and it solves the mutex initialization problems reported by Joe. If this
means apr-util/trunk disappears, that's fine.
Yeah, we need to sketch out how the DSO loading works API wise, and do
it in a generic way, such that most of the symbols exist in the main
library, but at runtime we can pull in a bunch of libraries.
For example, apr_ldap_open or apr_dbm_open should exist, but we
shouldn't hard link to libldap or libdb46 instead perhaps have shim
shared DSOs that we load, libapr-ldap.so, which are linked to them. I
think an approach like this could work on most Linux/BSD/OSX type
places, but I'm sure it will have problems on some rarer unix OS.
But doing this is anotheer reason to do it in SCons, it would make all
the dynamic/static libs compiling much easier.
and apr-iconv into apr trunk.
-1; we need a different solution. citrus, something based on the work of
the perl community (automated), or even IBM's ICU. There isn't the long
term interest in maintaining this.
Do we even need it at all? Can't we just remove it and tell people to
use IBM's ICU? (or another library?)
2. move to a SCons-build system (if you don't have Python available in
2009, your OS sucks)
Create a sandbox, demonstrate it. Same goes for cmake fans. Time for a
shootout to eliminate our current headaches.
3. make pools runtime-configurable whether they are just a thin
malloc()/free() wrapper or do internal reuse
Interesting, looking forwards to patches :)
Huge +1 to doing this.
I'm volunteering to do the grunt work for 1. I think I know someone
who might volunteer for #2 (*nudge*). And, #3 shouldn't be terribly
hard to accomplish as long as we keep the pool API the same. If we
want to tweak the pool API, then that's far more involved.
#2 is mine I guess :P
-Paul
