Hi, i am a bit confused now, will ICU be hard dependency on 5.0 instead of 5.1? As i already mentioned we are having problems with a hard ICU dependency for WindowsCE as its not supported by the ICU buildsystem.
Will ICU become part of the 3rdparty repo with a more cross platform friendly buildsystem? As of know its a huge linux configure script and i was unable to even generate my own visual studio solution with the proposed cygwin setup. The only way to get a working windows build is use the shipped sln file which requires a new visual studio. In general i don't know how open the ICU guys are to new platforms. But i see this as a larger problem for porting qt to a non unix platform. I get the reason why ICU is a good idea for supported platforms, but is there a reason to enforce it on all platforms? Best regards Björn Breitmeyer Am Dienstag, 31. Juli 2012, 14:00:10 schrieb Thiago Macieira: > Quick discussion on IRC happened. This is a summary of the discussion and > proposal for the SDK. > > Situation: > > The ICU libraries *do* offer a stable C API, which they say they will > maintain and keep compatible. However, the library soname changes on every > version and most distributors enable symbol renaming. That means we cannot > depend on the stable API. > > What's more, ICU may or may not be present on some systems. > > On WIndows, it's not present. Therefore, we need to supply our own ICU > anyway. Any Windows programs will need to ship it and our deployment > instructions should be adapted to match. > > On iOS, it is present but dlopen is not available to applications. > Therefore, we must link to it anyway (note: I don't know if App Store rules > permit that). If the ICU versions do change on different iOS versions, then > application developers will need to create multiple versions of their > applications. > > For Linux distribution packages, the version of ICU is tightly controlled by > the distributors. Therefore, linking to it is no problem and should be the > default. This is also the default for people downloading and building from > sources. > > The problem remains for the Linux and Mac SDKs and for Android. I don't know > the situation on QNX, but it is either this case or the one above of > distribution packages. > > For the Linux and Mac SDKs, we *can* get away with shipping our own copy of > ICU, just like it will be done for Windows. For Android, it would be > preferable if we could dlopen the library. If we have the code to dlopen, > however, then we could also use it for Linux and Mac SDKs. Unfortunately, > due to the symbol renaming, soname renaming and the QtWebKit dependency, > this solution is too much work for 5.0. > > Proposal: > > We propose then that for the 5.0 SDK packages, we ship our own copy of ICU, > in all cases. It's already done for Windows. I'd also recommend going > further and using ICU's own renaming system to insert a "q" in the function > names and soname so they don't conflict with the system. > > As a 5.1 task, we propose investigating the searching+dlopen solution. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development