At 07:32 PM 3/16/2005, Justin Erenkrantz wrote: >--On Wednesday, March 16, 2005 7:02 PM -0600 "William A. Rowe, Jr." <[EMAIL >PROTECTED]> 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
