[haiku-gsoc] Re: Do we ICU or do we not ICU?

  • From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
  • To: haiku-gsoc@xxxxxxxxxxxxx
  • Date: Mon, 15 Jun 2009 15:10:51 +0200

On 2009-06-15 at 14:29:42 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
wrote:
> PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
[...]
> > I wanted to know what is the decision on this (if one has been made).
> > I have been working on the catalog translating part of my project,
> > but
> > this part is now almost finished and I would like to know if I should
> > start messing with ICU build system, how would it be integrated
> > (piston, svn external, copy of the sources to haiku's repository,
> > other solution ?)

I am going to add ICU to the locale kit branch soon (doing a vendor branch 
and then copying the stuff). IMHO svn-externals make no sense at all, since 
all they do is to add yet another repository one depends on.

> 
> Not sure if there was an actual decision, but I would start by
> importing ICU into our build system, and then start using it. I guess
> we'll see how much we want to use of it, and how to best use it then.
> In any case, there should be a tight integration, ie. the POSIX locale
> implementation should use the same backend as liblocale.so. 

I personally would leave the POSIX stuff alone completely for now. The 
libroot we have is a mess and we have to get rid of it sooner or later, so it 
does not really make sense to wrestle the locale stuff into it. 
On top of that, the POSIX stuff was not even mentioned as part of the GSOC 
project description, so unless Adrien feels an urge to work on that, I'd say 
we better leave it out.
I'd rather like to see work on liblocale.so done, such that it the Locale Kit 
API works and we can start to use it. If at that time we feel that ICU is a 
good backend solution, we could start to use it from libroot, too.

The main problem here, of course is, that this would only really make sense 
if our libroot has an abstract interface for the locale stuff. AFAICS, this 
is not the case with glibc, is it?
Does anyone know if the BSD-libc has such an internal interface? Because I 
suppose if there's no libc with a separatable locale "module", using ICU as 
the locale backend will be rather difficult (or pointless, on the POSIX 
level).
OTOH, if we have to use the locale stuff that comes with our "next" libroot, 
since it is forced upon us by the internal design, we could use that as the 
backend for the Locale Kit API, too, leaving no (or not much) room for ICU.
To me, it looks as if we really should make up our heads about which way to 
go with libroot. Most probably not before R1, though.

> But I don't
> particularly care if the latter is a wrapper around ICU or not.
> Just don't be afraid to discard existing liblocale code if ICU's
> counterpart is better suited. I would like to see the liblocale API
> more or less retained, though, unless there is a good reason.

Agreed.

cheers,
        Oliver

Other related posts: