[Webkit-unassigned] [Bug 22713] Confusing/repetitive onboard unicode sources

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Dec 7 01:24:02 PST 2008


------- Comment #5 from mrowe at apple.com  2008-12-07 01:24 PDT -------
(In reply to comment #4)
> (In reply to comment #3)
> > Mac OS X ships with ICU, but doesn't ship with headers.  The WebKit tree
> > includes copies of the headers so that the system version of the library can be
> > used.
> I'm aware that OS X ships ICU libs but not headers, so it's great that WebKit
> itself has a copy of those missing files. But why does it need three copies of
> those files?

Each WebKit project needs to be able to build independently of the others.

> Also, given that ICU is a generally useful thing, users may have ICU from some
> other vendor, installed in a more complete fashion (i.e., with headers).Given
> that it's an external lib (from perspective of WebKit), why not use it
> externally? Worse, if user does have a different ICU version installed, you're
> forcing use of headers (via local -I) that may not match the globally available
> lib (found via -l, there is no local -L for the lib). Even assuming a vanilla
> OS X system, 10.5 and 10.4 have different versions of ICU so half the time (as
> of public supported OS X releases:) you're *forcing* use of mismatched headers.
> Fink among other vendors can install global headers "that match OS X headerless
> lib", so I can be sure I get a matched set.

I made no statements about what behaviour the GTK port should take when
building on Darwin, I simply pointed out why the headers are in the WebKit
tree.  Note that there is no problem in building against the 10.4 ICU headers
but using the 10.5 ICU library.  If there were problems with that it would
indicate that ICU did not maintain source- and binary-level compatibility
between releases.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list