[openbeos] Re: CVS: current/src/kits/support Jamfile,1.3,1.4

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Thu, 31 Jul 2003 15:13:36 +0200 CEST

"Andrew Bachmann" <shatty@xxxxxxxxxxxxx> wrote:
> > Do we want to have a separate libiconv.so later in OpenBeOS?
> > Or as part of libroot.so? Or as part of libtextencoding.so?
> Ah.. I don't know how this email snuck past my sensors.  This is a 
> question that I also wanted to pose as part of the earlier mess.  I 
> think in principle I prefer the combination of more, smaller 
> libraries 
> and linking libraries to libraries.  So I suppose it's no surprise 
> that I 
> linked libtextencoding.so to libiconv.so.  Presumably we are going 
> to expose iconv since it is in our headers.

My preferred solution would be to expose both, the Be 
convert_{to,from}_utf8() API and iconv from libtextencoding.so - since 
that's what iconv is about: text encodings. And since the Be API seems 
to be such a small wrapper around it, I see no point in putting it into 
a separate library.
Moreover, the functionality of the Be API relies on the presence of a 
compatible iconv implementation - the best way to ensure their 
compatibility is to put them together into one library, avoiding the 
possibility to upgrade one of them without the other.
Finally, that's also better in terms of startup time and memory usage.

Considering OpenBeOS to be an undividable entity would also open up the 
possibility to move iconv into libroot.so (or even have a separate 
libiconv.so), but I somehow don't think it's such a good idea, simply 
because I don't think that this single entity exists in such a strong 
way.
If GNU's libio stuff which we will inherit for our libroot.so depends 
on iconv (I somehow remember something like this), then this would be a 
strong argument to put it into libroot.so directly - but we might as 
well consider removing that dependency altogether.

Adios...
   Axel.

Other related posts:

  1. Home
  2. haiku
  3. Archive
  4. 07-2003