[Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake

[Konstantin Tokarev]

28.04.2017, 18:58, "Thiago Macieira" <thiago.macieira at intel.com>:
> 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.

I understand your point, but it seems impractical to provide wrapper qmake project
as an interface for packagers. They know know how to deal with qmake or cmake
packages, but dealing with cmake wrapped with qmake is a totally different business,
and can easily double amount of issues to solve, especially when cross-compiling.
That said, it works fine in Coin.

Maintaining old qmake-based build was not considered because I don't have
resources to maintain a build system that duplicate's one maintained by upstream.
If there are volunteers to do that I can reconsider, but note that you will have to deal
with lots of custom code generators, that are changed over time, and it would be
much harder to backport upsream patches (that already include necessary cmake
changes)

As a side effect, having cmake build that is usable as a public build interface helps
with IDE integration, e.g. I'm using existing cmake support in Qt Creator for development.

>
>>  * 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.

Fine with me. Looks like the problem is that archive [1] contains only necessary files,
but [2] contains all ICU libraries + unversioned links. Archive [2] is unpacked into
SDK image since 5.8.0.

[1] http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel6.6-x64.7z

Files:

Extracting  libicudata.so.56
Extracting  libicui18n.so.56
Extracting  libicuuc.so.56
Extracting  libicudata.so.56.1
Extracting  libicui18n.so.56.1
Extracting  libicuuc.so.56.1

[2] http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel7.2-x64.7z

Files:

Extracting  libicudata.so
Extracting  libicui18n.so
Extracting  libicuio.so
Extracting  libicule.so
Extracting  libiculx.so
Extracting  libicutest.so
Extracting  libicutu.so
Extracting  libicuuc.so
Extracting  libicudata.so.56
Extracting  libicui18n.so.56
Extracting  libicuio.so.56
Extracting  libicule.so.56
Extracting  libiculx.so.56
Extracting  libicutest.so.56
Extracting  libicutu.so.56
Extracting  libicuuc.so.56
Extracting  libicudata.so.56.1
Extracting  libicui18n.so.56.1
Extracting  libicuio.so.56.1
Extracting  libicule.so.56.1
Extracting  libiculx.so.56.1
Extracting  libicutest.so.56.1
Extracting  libicutu.so.56.1
Extracting  libicuuc.so.56.1

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin