apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: The iconv solution?
Date Fri, 08 Dec 2000 23:32:43 GMT
+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/

Mime
View raw message