Policy regarding QtWebKit and QtScript

Kevin Kofler kevin.kofler at chello.at
Wed Jan 6 17:11:25 GMT 2016

Adriaan de Groot wrote:
>  - Why am I building ninja when it's already packaged externally?

export NINJA_PATH=/usr/bin/ninja
(or ninja-build or however your OS's package calls the binary)
is enough to fix that.

>  - Why am I building yasm?

Add GYP_CONFIG += "use_system_yasm=1" to your src/core/config/*.pri file.

>  - Same applies to most of the bundled stuff. A lot of the FreeBSD patches
>  for Chromium itself are, indeed, unbundlings.

Actually, a lot of the FreeBSD patches are adding BSD #ifdefs (or the gyp 
equivalent), I don't see much unbundling there. I see a fix for unbundling 
libusb1/libusbx (which is not needed for QtWebEngine because QtWebEngine 
does not use libusb*, by the way), maybe I'm missing 1 or 2 things, but 
unbundling doesn't seem to be the main focus. And the reason there are so 
many patches is because they produced a different patch for EVERY SINGLE 
source file they modified! (That, and the fact that they're only named after 
the source files and not after the modifications actually done, also makes 
it really hard to decide at a glance what those patches really do. IMHO, 
this is an example of how NOT to manage downstream patches.)

>  But those need to be re-done for webengine, because who knows how the
>  versions differ.

The Chromium patches should mostly work as is. Some will not be needed 
because QtWebEngine does not build everything from Chromium, but they 
shouldn't hurt either.

>  - The qmake and gyp (horse pucky!) are strongly tied into
>  linux/mac/boot2qt, so finding all the bits and pieces that need adjusting
>  is tricky.

The hardcoded list of operating systems is indeed a hindrance to 
portability. (Basically, "linux" should really be "any working OS, i.e. 
anything other than the broken Window$ and Mac crap".)

>  - Example, I thought I had bunged freebsd-clang into the system properly,
>  but gyp is still trying to discover the assembler version by calling gcc.

Are you already setting the:
GYP_CONFIG += clang=1 host_clang=1 clang_use_chrome_plugins=0 \
flags that desktop-linux.pri sets when building for a linux-clang target?

>  - Example from qt3d (so external to this discussion), using a broken
>  OffsetOf in a bundled third party library.

Yes, bundled libraries suck and this kind of issues is another reason why.

        Kevin Kofler

More information about the kde-core-devel mailing list