[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