[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