28.04.2017, 18:58, "Thiago Macieira" <thiago.macie...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development