Front page | perl.perl5.porters |
Postings from January 2010
Re: Use ICU for Unicode in Perl?
Thread Previous
|
Thread Next
From:
Craig A. Berry
Date:
January 29, 2010 07:44
Subject:
Re: Use ICU for Unicode in Perl?
Message ID:
c9ab31fc1001290744x34e2f31cg22091404d220b7db@mail.gmail.com
On Fri, Jan 29, 2010 at 3:18 AM, Nicholas Clark <nick@ccl4.org> wrote:
> On Thu, Jan 28, 2010 at 09:34:35PM -0700, karl williamson wrote:
>> I found only a couple of references to the ICU Unicode C language
>> library in the p5p archives. Is there a reason not to use some of this
>> open source code when it suits our purposes?
>
> Part of it, maybe. But
And then the question arises about what parts of it can live
independently of other parts. For example, does one still need C++ if
one only wants the C API, and can any of the code be used without all
of the (huge) data files?
It's a big package; the tarball is bigger than Perl's. A quick count
of the code shows:
.h, 153,500 lines in 657 files
.c, 216,073 lines in 255 files
.cpp, 575,757 in in 516 files
and it looks like there are a lot more data than code in the package.
> Building International Components for Unicode on UNIX requires:
>
> * A C++ compiler installed on the target machine (for example: gcc, CC, xlC_r, aCC, cxx, etc...).
> * An ANSI C compiler installed on the target machine (for example: cc).
> * A recent version of GNU make (3.80+).
It also includes solution files for building with Microsoft tools, so
the requirement for GNU make would appear to be a fairly thin one.
> Note that:
>
> 1: VMS is not in their list
I've never heard of a port nor could find one in a quick search.
Given that it runs on z/OS and Windows, I'd say it looks portable
enough that it should be possible.
> 2: It doesn't look like they've changed from an m*n configuration system - ie
>
> AIX HP/UX
> vendor compiler works works
> g++ works you need to port!
>
>
> ie they chose not to abstract out OS specific parts and compiler specific
> parts from their configuration system
>
> 3: gnu make has its own list of dependencies.
>
>
> And if it's all for UTF-16, then how much does that help us when we're using
> UTF-8 internally?
My impression was that karl is interested in borrowing and adapting
piecemeal rather than trying to outsource the whole Unicode problem or
adding libicu as a dependency. Grabbing a function or two that do
something useful sounds promising, though it's hard to say without
digging in how possible that is.
Thread Previous
|
Thread Next