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

[Simon Hausmann]

Hi,

Yeah, the rhel 7.2 icu packages on download.qt.io should not contain the .so symlinks.

Iikka, is this something you could help us with?

Simon

> On 29. Apr 2017, at 11:22, Konstantin Tokarev <annulen at yandex.ru> wrote:
> 
> 
> 
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development