apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: On to APR 2.0.0? Beyond 9x/ME
Date Sat, 03 Jan 2009 20:45:26 GMT
William A. Rowe, Jr. wrote:
> Justin Erenkrantz wrote:
>> On Fri, Jan 2, 2009 at 3:57 PM, William A. Rowe, Jr.
>> <wrowe@rowe-clan.net> 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


Mime
View raw message