[haiku-gsoc] Re: Do we ICU or do we not ICU?
- From: Oliver Tappe <ot@xxxxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Tue, 12 May 2009 10:17:33 +0200
On 2009-05-12 at 08:53:12 [+0200], PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> > I am strongly against importing big external libraries into the Haiku
> > source tree. There are plenty of tools now for linking external
> > libraries into an existing source tree. Some options for SVN are
> > svn:externals or Piston (http://piston.rubyforge.org/). We are surely
> > not the only project that needs to use a big library like ICU as a
> > core component, but don't want to put that code in their source
> > control. Let's see what the options are.
> >
> > Once we figure out something nice I would suggest maybe setting up
> > some other components like this (Mesa for one, probably several other
> > things.) The only things I would not move out is anything that is
> > deeply embedded or heavily modified (AGG and libc come to mind.)
> >
>
> The problem with this approach is that we are using jamfiles. So we
> need to change files on the upstream part. But piston sounds like a
> good tool for that :)
Yes, I mean we could keep the Jamfiles separated from the ICU source, but I
don't seem to grasp what using a svn:external would help? During the build,
this would surely have to be resolved, since ICU will always be part of the
build anyway, so the download is just delayed, not saved.
> > If it helps I was able to compile ICU 2.6 for WebKit back in 2007. I
> > believe others have done so since, so there may not be much "porting"
> > required. But obviously wrapping all that functionality in nice Haiku
> > kits is the challenge. By the way, there are some tricks that may be
> > required to cross-compile ICU, though that may have been fixed since I
> > had to compile it. I don't know if Adrien is doing this work from
> > within Haiku or from a cross-compile setup...
>
> I'm cross compiling from linux, and that is the biggest problem. If
> ICU isn't integrated in the build tree, I have to set up a lot of
> environment vars manually to get the haiku cross compiler to work.
> This would be done automatically by the jamfiles if ICU is inside the
> build tree.
I suppose we could just invoke configure natively on haiku and import the
resulting setup into our repo. Shouldn't that do the trick?
> Anyways, if we choose to use ICU, it has to be in the build tree,
> because the locale kit will be part of the core system, not an
> external project.
Yep, I think so, too. And if - one fine day - we replace our hacked glibc by
something more updatable, ICU might be useful to fill some holes in that new
libc (regex & posic locale).
cheers,
Oliver
Other related posts:
