apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: apr-iconv 1.0
Date Thu, 01 Jul 2004 23:41:25 GMT
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 

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
-- Brane

View raw message