[Development] ICU and Windows
John Layt
jlayt at kde.org
Fri Jan 11 17:29:03 CET 2013
On Friday 11 Jan 2013 13:32:35 Shaw Andy wrote:
> Since ICU doesn't provide the debug version of the libraries in their binary
> packages then this means that either the user has to build them themselves
> (which means modifying the target as well since the output for debug and
> release defaults to be the same in their project files) or we should
> consider adding them to the 3rdparty section (like we do for libegl and so
> on) so we can control the situation better.
>
> Either way I feel that this needs to be fixed ASAP because we could end up
> seeing bug reports that are in effect caused by this and end up creating
> more noise as a result. A short term option (and potentially permanent)
> would be to link against a different version of the ICU libraries and point
> out that if they want to use Qt in debug they would need to build ICU
> themselves and make the relevant modifications to the output library names.
Hi Andy,
I'm no expert on the various build and link issues, but in trying to write the
new ICU backend for QLocale which would make ICU a hard requirement in the
future I've started running into problems which may affect your choice of
solution.
For those interested, I have working code for ICU-based number and date
formatter classes at:
http://qt.gitorious.org/~odysseus/qt/odysseus-qtbase/commits/qlocale-icu
Up to now I've been using the ICU C api due to ICU not providing a binary
compatibility guarantee on their C++ api between major versions. This C api
is a simplified wrapper around the C++ implementation. This works fine for
the most commonly used functions like number and date formatting, but the C
api is completely inadequate for using the calendar and time zone functions,
which are a primary reason for switching to ICU. For example, you can't even
find out what the current time zone is via the C api, let alone create and
query a custom timezone in an efficient way.
I'm trying to find a way around this with just the C api, but right now the
easiest solution does appear to be using the C++ api and somehow dealing with
the binary compatibility problem. Could we make that work?
On Linux, I have heard that some/many distro's automatically rebuild all
packages depending on ICU whenever the ICU major version changes due to its
bad reputation. Could we simply just state that it is a requirement to
rebuild Qt if the ICU major version on a system is changed?
On Mac, because OSX doesn't ship with the ICU headers installed, my
understanding is we currently require people to install ICU via MacPorts or
HomeBrew and build against that instead of the system ICU libraries. I don't
see that as a long-term solution when we start requiring ICU as it's not very
portable or reliable as to the version used. The alternative is to manually
install the headers from opensource.apple.com and use the system library (how
I'm currently building), but I've heard there's been issues in the past with
published headers not actually matching? The best option is probably not to
use ICU at all on Mac, but just use the Carbon/Cocoa api which is actually
just a thin wrapper around ICU and for localization at least is complete for
our current purposes. However, I'm not sure this is an option for the other
proposed uses of ICU, such as code tables.
On Windows, well it almost seems we have to require people to either build
their own ICU and keep it in sync with Qt, or we have to start providing it
ourselves.
Perhaps the best solution is going to be including ICU in 3rdparty:
* On Linux always build with 3rdparty ICU, unless the distro/dev chooses to
use their system library and accepts the need to rebuild Qt with a major
version change.
* On Windows always build with the 3rdparty ICU, unless the dev wants to use
their own and takes responsibility for maintaining compatibility
* On Mac don't use ICU for QLocale, but use the native api instead, only build
3rdparty ICU if other features are enabled that need it. Alternatively trust
the opensource.apple.com headers and use the system library.
One plus point to shipping in 3rdparty is that we can use a more modern
version than the ICU 4.0 we're currently stuck with due to Snow Leopard
support. The big minus is ICU is big and possibly icky to build.
Cheers!
John.
More information about the Development
mailing list