Front page | perl.perl5.porters |
Postings from January 2010
On Fri, Jan 29, 2010 at 09:44:20AM -0600, Craig A. Berry wrote: > 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? I believe that Encode already uses some (many?) of its data files. Your question is the important one, and I don't know the answer. > > 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. That's the list "for UNIX". It makes it less than totally portable. > 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. Yes, mine to. Although we seemed to get digressed. But it all depends on the answer to your question above. Nicholas ClarkThread Previous | Thread Next