[Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake
Thiago Macieira
thiago.macieira at intel.com
Fri Apr 28 17:54:24 CEST 2017
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
More information about the Development
mailing list