You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/11/20 16:11:26 UTC
RE: cvs commit: apache-2.0/src/lib/apr/i18n/win32/iconv/ces - Newdirectory
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Monday, November 20, 2000 8:57 AM
>
> On 20 Nov 2000, Jeff Trawick wrote:
>
> > wrowe@locus.apache.org writes:
> >
> > > wrowe 00/11/20 05:32:04
> > >
> > > apache-2.0/src/lib/apr/i18n/win32/iconv/ces - New directory
> > >
> >
> > Ow... Perhaps it should have been obvious to me yesterday
> where you were
> > going to place an alternative translation library (but it
> wasn't :) )...
> >
> > not every Unix platform has iconv() (e.g., the FreeBSD box I have at
> > home)... I would have thought we would put this somewhere for all
> > platforms to use as appropriate
> >
> > perhaps not a problem and/or you've already thought of this...
> >
> > (going for more caffeine)
>
> This is my fault, so I will take the blame. Will asked me
> where I thought
> it should go, and I thought this was just for Win32
> platforms. If there
> are unix platforms that don't have this code, then we should do code
> sharing. There is no real problem where-ever this code
> lives, we could
> just compile out of that directory for any platform that needs it.
>
> I personally suggest that we move the code from win32/iconv to unix/iconv
> to be consistent. We will need to modify the unix i18n code to use this
> library iff there is no native support.
+1...
is there disagreement with merging the three packages into one tree?
(iconv, iconv-extra and iconv-rfc1345)
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.
Re: cvs commit: apache-2.0/src/lib/apr/i18n/win32/iconv/ces - Newdirectory
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > Sent: Monday, November 20, 2000 8:57 AM
> >
> > On 20 Nov 2000, Jeff Trawick wrote:
> >
> > > wrowe@locus.apache.org writes:
> > >
> > > > wrowe 00/11/20 05:32:04
> > > >
> > > > apache-2.0/src/lib/apr/i18n/win32/iconv/ces - New directory
> > > >
> > >
> > > Ow... Perhaps it should have been obvious to me yesterday
> > where you were
> > > going to place an alternative translation library (but it
> > wasn't :) )...
> > >
> > > not every Unix platform has iconv() (e.g., the FreeBSD box I have at
> > > home)... I would have thought we would put this somewhere for all
> > > platforms to use as appropriate
> > >
> > > perhaps not a problem and/or you've already thought of this...
> > >
> > > (going for more caffeine)
> >
> > This is my fault, so I will take the blame. Will asked me
> > where I thought
> > it should go, and I thought this was just for Win32
> > platforms. If there
> > are unix platforms that don't have this code, then we should do code
> > sharing. There is no real problem where-ever this code
> > lives, we could
> > just compile out of that directory for any platform that needs it.
> >
> > I personally suggest that we move the code from win32/iconv to unix/iconv
> > to be consistent. We will need to modify the unix i18n code to use this
> > library iff there is no native support.
>
> +1...
+1 from me for moving to unix/iconv (Real Soon Now) and for teaching
configure and the unix i18n code when to use this (when somebody needs
it or somebody has the time)
> is there disagreement with merging the three packages into one tree?
> (iconv, iconv-extra and iconv-rfc1345)
I'll trust your judgement... my generic concern is that it be simple
to upgrade to a later version of the package
> is there disagreement with yanking the GPL'ed docs?
we have to do that, I imagine... I guess we can replace it with a
single file that points to where the GPL-ed docs live? (hopefully
that form of linking in GPL-ed stuff is o.k. :) )
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/lib/apr/i18n/win32/iconv/ces -
Newdirectory
Posted by rb...@covalent.net.
> > 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.
>
> Note that "make distclean" is broken: "make distclean" from the Apache
> base directory is going into the i18n/win32/iconv directory, but on my
> systems the Makefile is bogus so it blows, causing make distclean to
> abort.
>
> There is logic for distclean in Sasha-land (build/rules.mk) which
> looks for everything named "Makefile" and does make distclean there.
> We could perhaps tweak build/rules.mk, but I think in general we don't
> want anything named Makefile to be committed.
There are multiple problems with this. 1) No Makefile should ever be
committed. 2) build/rules.mk should never be going into APR to do a make
distclean. It is up to APR to do the make distclean recursively, not
Apache.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/lib/apr/i18n/win32/iconv/ces - Newdirectory
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> > 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.
Note that "make distclean" is broken: "make distclean" from the Apache
base directory is going into the i18n/win32/iconv directory, but on my
systems the Makefile is bogus so it blows, causing make distclean to
abort.
There is logic for distclean in Sasha-land (build/rules.mk) which
looks for everything named "Makefile" and does make distclean there.
We could perhaps tweak build/rules.mk, but I think in general we don't
want anything named Makefile to be committed.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: cvs commit: apache-2.0/src/lib/apr/i18n/win32/iconv/ces -Newdirectory
Posted by "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
RE: cvs commit: apache-2.0/src/lib/apr/i18n/win32/iconv/ces -
Newdirectory
Posted by rb...@covalent.net.
> 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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------