11.01.2013, 20:29, "John Layt" <jl...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development