While we're on the subject of apr-iconv...
I'd like to reconsider the use of the APR_ICONV_PATH environment variable. It turns out it's evil if you have to install two different versions of apr_iconv in parallel. Also, on Windows, there's an issue of different runtime libraries used by different compilers, and in Subversion (or rather TortoiseSVN), we've seen instances where these can interfere because of the use of this env. var.
Therefore I propose to change the way apr_iconv looks for the loadable conversion modules in 1.0.
* Remove APR_ICONV_PATH
* On Unix, hardcode the path to the modules, using standard
configury. The default would be ${prefix}/lib/apr-iconv-${major},
or some such.
* On Windows, we'd calculate the path relative to the location of
the libapriconv-1.dll library; e.g.,
GerModuleFileName(0)/apr-iconv. Alternatively, the application
could pass in the root path, but we'd have to add an
initialization API -- we'd need something like that for the
statically-linked version.Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate.
William A. Rowe, Jr. wrote:
I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 - they are seperate subsets with their own set of issues.
APR 1.0 does not require apr-util or apr-iconv, there is no dependency. So no holdup of David's plans.
I'm proposing we switch around apr-iconv's interface to:
1) change typedef void *apr_icon_t; to an incomplete type, e.g.
typedef struct apr_icon_t apr_icon_t;
2) consistently use an apr_icon_t * or (for create) apr_icon_t ** as the arguments to the exposed functions.
3) reorder apr_iconv_open to pass the new apr_iconv_t ** placeholder as the first not last arg, consistent with apr.
4) drop apr_pool_t argument from _close, that should use the same pool as the associated _open.
I'm not suggesting using the apr_iconv_open()ed pool for xlate operations, those may be in a frequently recycled pool, as oppsed to a long lived pool used for apr_iconv_open (_close).
Of course, the apr_pool_t *p becomes a member of our internal apr_iconv_t structure.
Thoughts?
Bill
-- Brane
