Policy regarding QtWebKit and QtScript
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?
(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.
More information about the kde-core-devel