[openbeos] Re: suggestions: iconv.h, libiconv, and iconv

  • From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sat, 02 Aug 2003 00:39:58 +0200 CEST

On Sat, 02 Aug 2003 00:33:09 +0200 CEST "Axel Dörfler" <axeld@pinc-
software.de> wrote:
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > > "manually".  Should I check libiconv into our cvs somehow?  
> > > > Perhaps
> > > > in current/src/libs/iconv?  The build system is configure/
> > > > makefile, 
> > > > should I convert it to jam?
> > > Please not yet! As I said, we should have a deeper look at 
> > > libroots 
> > > needs first, and decide where to put it when we did that.
> > > I don't think there is a point in putting it in now, only to have 
> > > it 
> > > somewhere when it's going to be removed or moved soon (you 
> > > remember, stupid/simple CVS cannot move files around).
> > Does the location where it is checked in, in any way restrict, how 
> > it 
> > is used? I mean, we can still build a static library and link it 
> > into 
> > libroot. Or do you think of a tighter integration? That would make 
> > incorporating updates more complicated, I guess.
> 
> I don't necessarily think of a tighter integration, but iconv is part 
> of the glibc as well - and if we are really going to include it in 
> libroot.so, I don't see a reason why we should use the libiconv 
> version 
> in this case.
> And since other libraries are currently missing from our repository 
> as 
> well (like libpdf), I don't think we should import it now, when we 
> don't know where to put it yet - and mess up our repository 
> unnecessarily.
> At least, I don't see an urgent need to do it now, just to have it in 
> there.

I guess, you're right.

> Anyway, if we don't have a special directory for libtextencoding.so, 
> but use kits/support for that, I would put iconv in that directory as 
> well if it is to be part of libtextencoding, or kernel/libroot/posix 
> if 
> it's part of libroot.so, and libs/ if it's going to be an extra 
> library 
> - even if I would really dislike the latter, for the reasons 
> explained 
> earlier.

Having it in a separate dir should make incorporation of updates 
easier, I suppose. Haven't had a look at the library yet, though (if 
it's only one file, then it wouldn't really be worth it ;-).

CU, Ingo


Other related posts: