RE: cvs commit: apache-2.0/src/lib/apr/i18n/win32/iconv/ces -Newdirectory

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Monday, November 20, 2000 9:50 AM
> 
> > is there disagreement with yanking the GPL'ed docs?
> > 
> > If not, Ryan, please relocate this as you move the APR into it's own
> > tree.  I was expecting you aught to kill this branch as you roll the
> > tarball (for alpha8) and rather than put it under win32, move it
> > to unix as you create the apr tree.
> 
> I would prefer to do this is multiple stages.  In fact, this 
> is completely
> new code, so let's just do the re-locate now.
> 
> I will cvs rm -Rf that dir and cvs add it to i18n/unix in a half-hour
> unless I get a -1.  This dir will be part of the alpha, but 
> we won't be using it, so it won't compile anywhere.

As long as you get the Makefile resolved, that's cool.

I'm looking at ICU in tandem.  As I realize what's under the hood of
iconv, and disect it, I'm really beginning to believe that there is
a simple iconv thunk that could be created for ICU that covers all the
territory of both libraries, gives us all our localization, and would
then eliminate all redundancy of mappings.

In the meantime, my q to the list ... do we APRize the entire iconv
and link it into APR when iconv doesn't exist on the target machine?
The existing code is pure Unix/BSD, so anything useful needs to be
built upon it.  A few helpers should just be written into APR anyway,
we need a path walk (colon seperators on Unix, semicolons on Win32),
and a few other goodies.  iconv_module almost disappears, since we
already have very thorough dynamic library support.

If this is the consensus, I'll base draft one on this iconv code today,
and consider stripping down and using ICU's implementations another day
(not in the next few weeks :-)

Bill