On Friday, 28 April 2017 11:54:53 -03 Konstantin Tokarev wrote: > Hello, > > There is a strange situation involving official Qt SDK (>=5.8.0) binaries > for Linux, ICU, cmake, and WebKit project files, I'm not sure which side > really needs to be fixed. > > (Qt)WebKit uses custom module to find ICU, you can see its code at [1]. > Module uses quite popular practise of invoking pkg-config first, and then > performing search of libs and headers by passing them as HINTS to > find_path() and find_library(). Doing so allows to have a meaningful > fallback if pkg-config is missing, misconfigured, or e.g. returns host libs > when cross-compilation is needed.
qtwebkit is built using qmake, so any CMake modules are irrelevant at this point. CMake is only used for building user applications. > There are a few possible solutions: > > * Provide ICU headers as a part of Qt SDK too. This has a benefit that ICU > libraries, required for QtCore, can be reused in other projects that use Qt > and ICU, e.g. for building of experimental QtWebKit versions against binary > SDK. Out of scope and you should be using qmake. > * Remove unversioned symlinks like libicuuc.so from SDK, so that they > are not found by FindICU.cmake, and also by linker if it's given -licuuc That seems like the right solution for me. If we're not supplying the headers (and it's not our business to), then we shouldn't supply the *.so symlinks either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development