apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Hold horses, 1.1.1 solution
Date Thu, 17 Mar 2005 02:20:22 GMT
At 07:32 PM 3/16/2005, Justin Erenkrantz wrote:
>--On Wednesday, March 16, 2005 7:02 PM -0600 "William A. Rowe, Jr." <wrowe@rowe-clan.net>
wrote:
>
>>This would be a minor bump, if not a major bump due to our oversight.
>>Certainly can't be a subversion bump since it changes the user-visible
>>usage of APR_ICONV_PATH (to APR_ICONV1_PATH)  I thought about some
>>extra punctuation and decided dashes weren't kosher, an extra
>>underscore seems unnecessary.  If anyone feels differently, holler.
>
>If you are adding a symbol, yes, it'd be 1.1.0.  But, under our compatibility rules, it'd
have to retain APR_ICONV_PATH as a define in addition to APR_ICONV1_PATH.  -- justin

Actually our compatibility rules say nothing about external
env vars.  I agree in spirit.  However, any _application_ which
horks with APR_ICONV_PATH is potentially breaking existing apps.

Now What?

I'd almost be partial to both APR_ICONV0_PATH (ewww... that 0 does
look too much like an O) and APR_ICONV1_PATH.  Fallback, for -both-
would be APR_ICONV_PATH.

A better solution, over time I believe, is very Win32 specific.
We can inquire for the full pathname of the 'libapriconv.dll' 
library.  My suggestion is that we prepend that path to -any-
path list given.  Alternately, we insert it between APR_ICONV1_PATH
and APR_ICONV_PATH.

This only solves the whole problem if the 'default path' for 
apriconv-1 modules is renamed from iconv.  Otherwise, the same
conflict will persist.



Bill





Mime
View raw message