[Development] ICU and Windows

[Shaw 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.

What you are trying to do would not be affected at all in anyway by either solution, all I want to ensure is that the ICU libraries are built with -MD when used with the release version of Qt and -MDd when used with the debug version of Qt.  It doesn't effect the API of ICU at all in any way.  I only suggested that we bundle the source with Qt as it would make it easier to ensure that this took place and it seems that you would also benefit from bundling as well :)

Andy