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

[Konstantin Tokarev]

29.04.2017, 23:18, "Thiago Macieira" <thiago.macieira at intel.com>:
> On Saturday, 29 April 2017 06:22:20 -03 Konstantin Tokarev wrote:
>>  > 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.
>
> My point is that there should be no cmake involved at all. The qtwebkit build
> has worked with qmake for 10 years, why should it stop now?

It's getting to the side way from the original topic, but let me tell you the story of
WebKit build systems.

When Apple opened WebKit source, initially it had only build system based on
Xcode projects. Of course it didn't work for others, and every WebKit port started
to maintain own build system. Qt port, of course, used qmake. GTK port initially
used qmake as well to avoid duplicating work, but later switched to autotools.
Windows ports (AppleWin and WinCairo) used VS project files. wxWidgets port
used waf. Google used gyp for Chromium and makefiles for Android (that was a
separate port that time).

EFL port used CMake, but later other ports, namely Blackberry and WinCE, also
used its build system. Shared build system that could work for different WebKit
ports was born.

Time passed, several ports ceased their existence. In 2013 GTK port decided to
switch from autotools to this shared CMake build system. AppleWin and WinCairo
also switched. Apple maintains CMake build for Mac port as well, AFAIK it is not
used for production builds but provides faster build times, so they are evaluating if
they can do full switch in the future.

So, current state of WebKit build systems is:
* All active ports except iOS have cmake as the only build option, or at least as
one of the options (Mac)
* CMake is likely the only build system that could be accepted in case Qt port would
ever return to trunk, or any other new port 
* Port-independent improvements to CMake build that benefit Qt port are accepted
(and reviewed) by upstream.

>
>>  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)
>
> Was the one that used to exist removed?

Yes. After 3 years of being not updated, it would require a ton of changes and
debugging to work with new WebKit. Changed file lists (that are always in flux) is
only part of the probem. Other part is figuring out how code generation is done, that
would require analysis of cmake code and reimplementing it with qmake. WebKit has
lots of different code generators with lots of peculiarities, that resulted in very arcane
qmake code in the past. And my name is not Ossi, I'm just a mere mortal with very
limited magic abilities :)

Switching to CMake from the start allowed me to get things building very fast, without
even knowing all gory details. I would estimate net result of build system switch for
now as neutral, because a lot of work was required to make it working in Coin and to
restore installation layouts provided by qmake for free. However, I expect next updates
of WebKit engine mostly flawless on build system side, as Qt-specific parts won't need
huge modifications anymore, and port-independent changes will come from upstream
directly.

Bonus: in case of weird build issues like [1] I can now just backport necessary cmake
incantation instead of figuring everything myself.

[1] https://bugs.webkit.org/show_bug.cgi?id=161697

>
>>  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.
>
> And the existing qmake support in Qt Creator did not work?

It would work, if there was something to work with.

>
>>  >> * 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.
>
> Then let's do it.
>
> --
> 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