William A. Rowe, Jr. wrote:
> Let me please clarify, before people start SCREAMING, that the
> apr_xlate API
> moved to apr-util. It will either use the installed iconv, or our own
> apr-iconv
> which itself requires the apr portability API.
Not screaming ... yet. :-)
> As far as APR_HAVE_ICONV_H and APR_HAVE_ICONV, those are misplaced
> right now. I'm asking for help with the library detection. We need
> to determine
> this upfront, in apr, so we can decide if apr-iconv or the platform
> iconv aught to
> be used.
We should probably do something similar to what we're doing in
Subversion for Berkeley DB, Neon, APR, APR-util.
* On Unix, you can either drop the source of any of these packages
into the Subversion source tree, where it will be built along with
SVN, or you can pass a --with-<package>=/path option to point to
the package's installation; As a last resort, we'll look in
"standard" places (/usr/local, etc.).
* On Windows, we only support the first of these options -- dropping
the package into the source tree (except for BDB, where you have
to drop in the binaries, not the sources).
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).
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.
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.
Then there's the question of support for APR_DEFAULT_CHARSET and
APR_LOCALE_CHARSET. The obvious solution is to have
apr_os_defalt_charset() and apr_os_locale_charset() somewhere in APR,
and let apr_xlate_open use that. Alternatively, we could check at
configure time if iconv_open accepts "" and interprets it as the current
locale charset; that should be fairly standard, IIRC. (We'd still beed
those two functions in APR, though, so that apr-iconv can use them.)
>> The APR configury should still find the installed (native) iconv on
>> Unix.
>> That must _not_ change. I'd still argue for some form of my drop-in
>> iconv
>> support on Windows, because I can't for the life of me see how to get
>> apr-iconv actually working on Windows in a day or two.
>
>
> This evening, in fact, we will be building apr-iconv for the win32
> build of
> apr-util.
That's good news. Best of luck, FWIW.
> We need to revisit all of the libdb and libiconv issues for the win32
> platform. We have no unix-like standards that dictate where or how
> such things are shared globally on a win32 box. But I'm not about
> to commit undocumented gross hacks to force this all to work around
> one installation.
>
> openssl, iconv, db, ldap; all of these need to be revisited.
zlib comes to mind, too. I'd do it the same way as we're handling BDB in
Subversion -- the build scripts expect a binary package in a certain
directory. With a bit of scripting magic (similar to what my iconv
support patch does), we could make any of these libs optional.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 18 00:41:16 2002