Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <443AB80C.1040603@rowe-clan.net>
Date: Mon, 10 Apr 2006 14:54:52 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
MIME-Version: 1.0
To: Brad Nicholes <BNICHOLES@novell.com>
CC: dev@apr.apache.org
Subject: Re: One last analysis of *1.2* symbols
References: <44386968.4090509@rowe-clan.net> <44386D57.2000009@rowe-clan.net>
 <443A1D83.6720.00AC.0@novell.com>
In-Reply-To: <443A1D83.6720.00AC.0@novell.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Brad Nicholes wrote:
>>>>On 4/8/2006 at 8:11:35 pm, in message <44386D57.2000009@rowe-clan.net>,
> 
> "William A. Rowe, Jr." <wrowe@rowe-clan.net> wrote:
> 
>>Some observations inline.  In short, with a commit to Netware to export
>>apr_hashfunc_default as per Joe Orton ... I believe 1.2 is ready to T&R,
>>which I'll do as soon as I see Brad's commit.
>>
>>Bill
>>
>>William A. Rowe, Jr. wrote:
>>
>>>Attached are three deltas, linux, win32 and netware deltas
>>>
>>>(these are already stale due to a couple of fixes applied.)
>>>
>>>--- apr-1.2-linux	2006-04-08 20:49:46.000000000 -0500
>>>+++ apr-1.2-netware	2006-04-07 04:36:08.000000000 -0500
>>>-apr_current_hooking_module
>>
>> > -apr_debug_module_hooks
>>
>>The hook diagnostics aren't compiled on Netware?
>>
>> > -apr_global_hook_pool
>>
>>This one is actually serious since our macro wrappers in the consumer's
>>app uses the symbol.  Is there a chance that (like my mis-extracted linux
>>symbol lists) you omitted data exports?
> 
> These symbols are deprecated in favor of 
> 
> apr_hook_global_pool
> apr_hook_debug_enabled
> apr_hook_debug_current
> 
> which are all included in the NetWare export list.  I am not as concerned
> about the deprecated symbols since there is a favored alternative and nobody
> seems to be complaining that they are missing on the NetWare platform.

Given the versioning 'rules' (d: none) that apply to 0.9, I agree on 0.9 - not
sure I respect it on 1.2, but the problem is that they are data constants.  If
we deprecated these and REPLACED them that's a major screwup in binary compat
rules.  If someone wants to deprecate, they need to retain the existing binary
symbol and add the appropriate 'future compatibility' macro.

In any case, changing this would break compatibility, just like renaming the
libapr on win32 or netware to libapr-0 for 0.9, or libapr-1 for netware, so I'd
think we leave this alone.

Given that uptake of apr 1 has been slow (nothing that I am aware of until last
quarter of last year) I wouldn't take lack of feedback as confirmation ;-)

>>>-apr_dbm_type_sdbm
>>
>>Netware doesn't export the built-in sdbm implementation?
> 
> No, these symbols are part of a "private" include.  Therefore I assume
> they should not be part of a "public" api.

Fair enough by me, if someone wants them exported in 1.3, they should
adjust the headers to make this public.

>>>-apr_hashfunc_default
>>
>>This is fixed on win32.  I presume it aught to be patched on Netware.
>>Brad, could you jump on this so I can T&R?
> 
> Now that it is decorated, it show up in the NetWare export list.

Badda bing, badda boom.  Glad it's that trivial (as long as it's in the
list of functions.)

So I presume from your list that apr and aprutil build as a single dynamic
object in apr 0.9, and 1.x?  Could we get this right and split them when
apr 2.0 ships out?  Already, several projects use only apr, and don't wish
to have all the apr-util baggage.  [Of course, there's the broader discuss
to happen about splitting apr into dependency-related groupings, but that's
a topic for another day :-]

I'd really like to have the build for apr-util not depend on resource lists
in the apr repository, e.g. the need to add apu_version.h to a dependency list.

Bill