You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/12/08 16:18:18 UTC
The iconv solution?
Suggestion,
It's impossible to maintain the whole of iconv within the apr tree,
the thing is just too big and harms folks who already have it installed.
But, since this is a bsd thing that we need to make more portable, I'm
suggesting we institute its own apr-iconv repository.
Long term, I'd like to see a portable implementation of the build for
xlate/iconv/lib housed in apr, that can be statically linked into apr.
This would eliminate a bunch of code and portability questions. But the
ces and ccs modules, as folks want them, should be checked out of
apr-iconv, since they shouldn't pose portability concerns (or can be
patched if they do).
If this is agreeable, I'd let someone create the apr-iconv cvs and I'll
move the sources over there. I'd like to do this today, before we roll.
Bill
RE: The iconv solution?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Friday, December 08, 2000 5:33 PM
>
> +1 from me! get that big beast outta APR
>
> I'm not sure about nuking stuff in the repository, though. Since OtherBill
> shoved the mess into the repository before the last alpha (bad!), they have
> now been tagged and were delivered as part of 2.0a8.
And so? It's an alpha (not a release) and nobody was basing code on that
branch. Let's move it out :-)
Re: The iconv solution?
Posted by Greg Stein <gs...@lyra.org>.
+1 from me! get that big beast outta APR
I'm not sure about nuking stuff in the repository, though. Since OtherBill
shoved the mess into the repository before the last alpha (bad!), they have
now been tagged and were delivered as part of 2.0a8.
Cheers,
-g
On Fri, Dec 08, 2000 at 12:15:18PM -0800, rbb@covalent.net wrote:
>
> My own opinion, and I believe this matches with Bill's is that we can't
> distribute iconv with APR, because it is just too big. I would like to
> put stub functions into APR, that can load iconv codepages, given a
> path. This would mean that any program that wants to use codepages will
> need to prep them first, but that is okay. Then, we put the codepages
> into the own repository, and create a tar ball that is accessible from the
> web site.
>
> Ryan
>
> On Fri, 8 Dec 2000, William A. Rowe, Jr. wrote:
>
> > Please comment to this, I think Greg, Jeff, Ryan and I were on the
> > same page on this, but I won't go ahead without a vote. I'd like it
> > to happen Saturday, since we don't seem to be rolling till Monday,
> > and I'd like to set Mon 00:00 GMT as the last chance to get your
> > tree checked out before we start blasting attics :-)
> >
> > Bill
> >
> > > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> > > Sent: Friday, December 08, 2000 9:18 AM
> > >
> > > Suggestion,
> > >
> > > It's impossible to maintain the whole of iconv within the apr tree,
> > > the thing is just too big and harms folks who already have it
> > > installed.
> > > But, since this is a bsd thing that we need to make more
> > > portable, I'm
> > > suggesting we institute its own apr-iconv repository.
> > >
> > > Long term, I'd like to see a portable implementation of the
> > > build for
> > > xlate/iconv/lib housed in apr, that can be statically linked into apr.
> > > This would eliminate a bunch of code and portability
> > > questions. But the
> > > ces and ccs modules, as folks want them, should be checked out of
> > > apr-iconv, since they shouldn't pose portability concerns (or can be
> > > patched if they do).
> > >
> > > If this is agreeable, I'd let someone create the apr-iconv
> > > cvs and I'll
> > > move the sources over there. I'd like to do this today,
> > > before we roll.
> > >
> > > Bill
> > >
> > >
> >
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
Greg Stein, http://www.lyra.org/
Re: The iconv solution?
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> My own opinion, and I believe this matches with Bill's is that we can't
> distribute iconv with APR, because it is just too big. I would like to
> put stub functions into APR, that can load iconv codepages, given a
> path. This would mean that any program that wants to use codepages will
> need to prep them first, but that is okay. Then, we put the codepages
> into the own repository, and create a tar ball that is accessible from the
> web site.
+1 from me, as long as we use the apr+apr-iconv-provided iconv only
when the system doesn't provide one or we determine that the
system-provided one is bogus
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: The iconv solution?
Posted by rb...@covalent.net.
My own opinion, and I believe this matches with Bill's is that we can't
distribute iconv with APR, because it is just too big. I would like to
put stub functions into APR, that can load iconv codepages, given a
path. This would mean that any program that wants to use codepages will
need to prep them first, but that is okay. Then, we put the codepages
into the own repository, and create a tar ball that is accessible from the
web site.
Ryan
On Fri, 8 Dec 2000, William A. Rowe, Jr. wrote:
> Please comment to this, I think Greg, Jeff, Ryan and I were on the
> same page on this, but I won't go ahead without a vote. I'd like it
> to happen Saturday, since we don't seem to be rolling till Monday,
> and I'd like to set Mon 00:00 GMT as the last chance to get your
> tree checked out before we start blasting attics :-)
>
> Bill
>
> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> > Sent: Friday, December 08, 2000 9:18 AM
> >
> > Suggestion,
> >
> > It's impossible to maintain the whole of iconv within the apr tree,
> > the thing is just too big and harms folks who already have it
> > installed.
> > But, since this is a bsd thing that we need to make more
> > portable, I'm
> > suggesting we institute its own apr-iconv repository.
> >
> > Long term, I'd like to see a portable implementation of the
> > build for
> > xlate/iconv/lib housed in apr, that can be statically linked into apr.
> > This would eliminate a bunch of code and portability
> > questions. But the
> > ces and ccs modules, as folks want them, should be checked out of
> > apr-iconv, since they shouldn't pose portability concerns (or can be
> > patched if they do).
> >
> > If this is agreeable, I'd let someone create the apr-iconv
> > cvs and I'll
> > move the sources over there. I'd like to do this today,
> > before we roll.
> >
> > Bill
> >
> >
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: The iconv solution?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Please comment to this, I think Greg, Jeff, Ryan and I were on the
same page on this, but I won't go ahead without a vote. I'd like it
to happen Saturday, since we don't seem to be rolling till Monday,
and I'd like to set Mon 00:00 GMT as the last chance to get your
tree checked out before we start blasting attics :-)
Bill
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Friday, December 08, 2000 9:18 AM
>
> Suggestion,
>
> It's impossible to maintain the whole of iconv within the apr tree,
> the thing is just too big and harms folks who already have it
> installed.
> But, since this is a bsd thing that we need to make more
> portable, I'm
> suggesting we institute its own apr-iconv repository.
>
> Long term, I'd like to see a portable implementation of the
> build for
> xlate/iconv/lib housed in apr, that can be statically linked into apr.
> This would eliminate a bunch of code and portability
> questions. But the
> ces and ccs modules, as folks want them, should be checked out of
> apr-iconv, since they shouldn't pose portability concerns (or can be
> patched if they do).
>
> If this is agreeable, I'd let someone create the apr-iconv
> cvs and I'll
> move the sources over there. I'd like to do this today,
> before we roll.
>
> Bill
>
>