apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Fogel <kfo...@newton.ch.collab.net>
Subject Re: utf8 not working with latest APR
Date Thu, 18 Jul 2002 14:54:41 GMT
Branko ─îibej <brane@xbc.nu> writes:
> Ho hum. Just noticed this wasn't Cc:'d to dev@apr ... Feel free to add
> that in the reply.

Sigh.  Sorry, I made the obvious mistaken when replying the first
time.  Here's my same mail again -- reply to *this* one, folks :-).

> Translating that to APR and the iconv case, I'd suggest, for Unix:
> 
>    1. Look into some standard place for the apr-iconv sources. If
>       they're there, use them.
>    2. Otherwise, check for --with-iconv=/path, and use the iconv
>       installed there (this could be any iconv package, potentially even
>       apr-iconv).

Are these reversed?  Shouldn't the --with-iconv=/path case override
absolutely anything else, and indeed fail if /path doesn't contain a
working iconv, even if there is a working iconv in some other standard
place on the system?

IOW, I would think steps 1 and 2 should be:

    1. Check for --with-iconv=/path, and use the iconv installed
       there.  Error right away if no iconv installed there.

    2. Look into some standard place for the apr-iconv sources. If
       they're there, use them.

>    3. Last chance: use standard configury tests to determine if the
>       iconv API is magically available from the "standard" places.
>    4. Otherwise, use the APR_ENOTIMPL variants of apr_xlate_* and friends.

Yep.

> On Windows, I'd like to support (1), or if the source isn't there,
> look in some standard place (a directory parallel to the apr-util
> sources?) for iconv binaries (include/iconv.h and
> lib/libiconv.h). That can be done fairly easily with a bit of
> scripting.

Sounds good to me.

-K

Mime
View raw message