Branko Äibej <[EMAIL PROTECTED]> writes:
> Ho hum. Just noticed this wasn't Cc:'d to [EMAIL PROTECTED] ... 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
