[Development] ICU and Windows

[Konstantin Tokarev]

11.01.2013, 20:29, "John Layt" <jlayt at kde.org>:
> 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.

It's icky to cross-compile, otherwise bearable. Size comes only from bundled
data, if you can use external dat file, your ICU may be quite small.

>
> Cheers!
>
> John.
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin