[v3,08/11] webkitgtk24: new package

Add new webkitgtk24 package.

The difference with the legacy webkit package is that this one uses the
new webkit2 API, and optionally the webkit1 API.

It's versioned because the latest release of midori can't use the newer
2.6.x or 2.8.x webkitgtk versions yet.

This paves the way for a newer webkitgtk26 or webkitgtk28 package that
can live side-by-side with this one for other uses.

Some loose checks (like !xorg7) are in place for possible/future wayland
support.
Right now wayland requires gtk2, hence xorg, but it might be possible to
patch that out with some work (it seems to be done for version 2.6.x,
though the build system changed to cmake so it might not be a
straighfoward patch).

Choices had to be made in the GL-area, right now the preference order is
libGL (full OpenGL), then GLES, then nothing (obviously).
And when gtk3 is around it's also preferred as well.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/Config.in                             |   1 +
 package/webkitgtk24/0001-fix-bug-137640.patch |  17 ++++
 package/webkitgtk24/Config.in                 |  56 ++++++++++++++
 package/webkitgtk24/webkitgtk24.hash          |   2 +
 package/webkitgtk24/webkitgtk24.mk            | 107 ++++++++++++++++++++++++++
 5 files changed, 183 insertions(+)
 create mode 100644 package/webkitgtk24/0001-fix-bug-137640.patch
 create mode 100644 package/webkitgtk24/Config.in
 create mode 100644 package/webkitgtk24/webkitgtk24.hash
 create mode 100644 package/webkitgtk24/webkitgtk24.mk

Dear Gustavo Zacarias,

On Sun, 19 Apr 2015 06:48:23 -0300, Gustavo Zacarias wrote:
> Add new webkitgtk24 package.
> 
> The difference with the legacy webkit package is that this one uses the
> new webkit2 API, and optionally the webkit1 API.
> 
> It's versioned because the latest release of midori can't use the newer
> 2.6.x or 2.8.x webkitgtk versions yet.
> 
> This paves the way for a newer webkitgtk26 or webkitgtk28 package that
> can live side-by-side with this one for other uses.

I'm a bit unhappy with webkitgtk24 as the name. Are the newer versions
API incompatible? Also, is it possible to install both webkitgtk24 and
webkitgtk26 or 28 on the same system?

> diff --git a/package/webkitgtk24/Config.in b/package/webkitgtk24/Config.in
> new file mode 100644
> index 0000000..2057546
> --- /dev/null
> +++ b/package/webkitgtk24/Config.in
> @@ -0,0 +1,56 @@
> +config BR2_PACKAGE_WEBKITGTK24_ARCH_SUPPORTS
> +	bool
> +	# ARM needs BLX, so v5t+
> +	default y if (BR2_arm || BR2_armeb) && !BR2_ARM_CPU_ARMV4
> +	# i386 / x86_64 external toolchains have issues
> +	# https://bugs.webkit.org/show_bug.cgi?id=132231
> +	# https://stackoverflow.com/questions/9140019/yield-is-not-a-member-of-stdthis-thread
> +	default y if BR2_i386 || BR2_x86_64
> +	depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_X86_201209
> +	depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_X86_201203
> +	depends on !BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_X86_201109
> +	# Disabled on powerpc due to bug https://bugs.webkit.org/show_bug.cgi?id=113638
> +	# Disabled on mips due to sigbus
> +	depends on BR2_USE_MMU # libglib2

Wow, so all in all, it's only available on ARM and x86/x86-64. Not a
huge list of supported architectures. But OK.

> +
> +comment "webkitgtk24 needs libgtk2 and a toolchain w/ C++, wchar, NPTL"
> +	depends on BR2_PACKAGE_WEBKITGTK24_ARCH_SUPPORTS
> +	depends on BR2_ARCH_HAS_ATOMICS
> +	depends on !BR2_PACKAGE_LIBGTK2 || !BR2_TOOLCHAIN_HAS_THREADS_NPTL \
> +		|| !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR
> +	depends on BR2_USE_MMU
> +
> +config BR2_PACKAGE_WEBKITGTK24
> +	bool "webkitgtk 2.4.x"
> +	depends on BR2_INSTALL_LIBSTDCPP
> +	depends on BR2_USE_WCHAR
> +	depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
> +	depends on (BR2_PACKAGE_LIBGTK2 && BR2_PACKAGE_XORG7)

Here you require gtk2 + xorg7, but not in the comment above. Is this
expected?

> +	depends on BR2_PACKAGE_WEBKITGTK24_ARCH_SUPPORTS
> +	depends on BR2_ARCH_HAS_ATOMICS
> +	select BR2_PACKAGE_CAIRO
> +	select BR2_PACKAGE_CAIRO_PNG
> +	select BR2_PACKAGE_ENCHANT
> +	select BR2_PACKAGE_HARFBUZZ
> +	select BR2_PACKAGE_ICU
> +	select BR2_PACKAGE_JPEG
> +	select BR2_PACKAGE_LIBCURL
> +	select BR2_PACKAGE_LIBSECRET
> +	select BR2_PACKAGE_LIBSOUP
> +	select BR2_PACKAGE_LIBXML2
> +	select BR2_PACKAGE_LIBXSLT
> +	select BR2_PACKAGE_SQLITE
> +	select BR2_PACKAGE_WEBP
> +	select BR2_PACKAGE_XLIB_LIBXT if BR2_PACKAGE_XORG7
> +	# MESA3D because it wants xcomposite/xdamage if GL/glx.h is found
> +	# even if the GL* backends are disabled
> +	select BR2_PACKAGE_XLIB_LIBXCOMPOSITE if BR2_PACKAGE_HAS_LIBGL || \
> +		(BR2_PACKAGE_HAS_LIBGLES && BR2_PACKAGE_HAS_LIBEGL) || \
> +		BR2_PACKAGE_MESA3D

The libgles + libegl case looks a bit weird. Such a configuration is
normally used *without* X.org, so why would we select some X.org
libraries in this case?


> +# make 3.81 loops into oblivion with numjobs > 1
> +ifeq ($(findstring x3.81,x$(MAKE_VERSION)),)
> +WEBKITGTK24_MAKE = $(MAKE1)
> +endif

Aah, that's how you solved the infinite loop.

> +# Give explicit path to icu-config and prevent ar to make thin archives.
> +WEBKITGTK24_CONF_ENV = ac_cv_path_icu_config=$(STAGING_DIR)/usr/bin/icu-config \
> +	AR_FLAGS="cru"

"prevent ar from making thin archives" ?

And why? :-)

> +# Some 32-bit architectures need libatomic support for 64-bit ops
> +ifeq ($(BR2_i386)$(BR2_mips)$(BR2_mipsel),y)
> +WEBKITGTK24_CONF_ENV += LIBS="-latomic"
> +endif
> +
> +WEBKITGTK24_CONF_OPTS = \
> +	--enable-dependency-tracking \

Why? Yes it is in the older webkit, but do we have a reason to have it
here?

Thanks!

Thomas

On 04/19/2015 09:49 AM, Thomas Petazzoni wrote:

> I'm a bit unhappy with webkitgtk24 as the name. Are the newer versions
> API incompatible? Also, is it possible to install both webkitgtk24 and
> webkitgtk26 or 28 on the same system?

Hi.
I'm not happy with the naming either, it's crappy to type/autocomplete.
But yes, multiple versions can live side-by-side and the API isn't
exactly the same.
In fact i have quite a setup with a webkitgtk26 package (in process of
going 28) but didn't send it yet because there are no applications in
buildroot that use it.
Midori can't use 2.6.x or 2.8.x, that's probably expected for a future
release (0.6.x+).
Versions 2.6.x/2.8.x can be used with epiphany (AKA web), but that would
require adding many new gnome3 packages and i'm not that fond of it (and
much less having time for it).

> Wow, so all in all, it's only available on ARM and x86/x86-64. Not a
> huge list of supported architectures. But OK.

This is just what i managed to get building and running.
A couple of mips combinations failed to build, one built but segfaulted
and i didn't test extensively because of build times.
The mips failures might be qemu's fault to be honest, at least those
that didn't run properly.
Powerpc needs some build patches, and i lack any ppc with framebuffer to
test (plus they're not a normal setup either).
I didn't try "fringe" or resource-constrained architectures.
And it's subject to available hardware to test as well, qemu is usable
but painfully slow :)
So right now it's "documentation" - these are known to work but doesn't
mean others won't.
I was hoping all of the people claiming for "i want new webkit!!!!1!!1"
would do some testing and feedback, but they're awfully silent on the
matter.

>> +comment "webkitgtk24 needs libgtk2 and a toolchain w/ C++, wchar, NPTL"
>> +	depends on BR2_PACKAGE_WEBKITGTK24_ARCH_SUPPORTS
>> +	depends on BR2_ARCH_HAS_ATOMICS
>> +	depends on !BR2_PACKAGE_LIBGTK2 || !BR2_TOOLCHAIN_HAS_THREADS_NPTL \
>> +		|| !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR
>> +	depends on BR2_USE_MMU
>> +
>> +config BR2_PACKAGE_WEBKITGTK24
>> +	bool "webkitgtk 2.4.x"
>> +	depends on BR2_INSTALL_LIBSTDCPP
>> +	depends on BR2_USE_WCHAR
>> +	depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
>> +	depends on (BR2_PACKAGE_LIBGTK2 && BR2_PACKAGE_XORG7)

> Here you require gtk2 + xorg7, but not in the comment above. Is this
> expected?

No, it's a leftover from wayland experimentation, it needs a fix.

> The libgles + libegl case looks a bit weird. Such a configuration is
> normally used *without* X.org, so why would we select some X.org
> libraries in this case?

Right now webkit 2.4.x can't build without gtk2+ and that's the reason
for it, we need xorg7 no matter what.
That's also the reason i dropped my attempts at wayland support, having
xorg7 there negates many of the benefits of such a setup.
It might be possible to patch the xorg/gtk2 needs away, it's already
done for 2.6.x+ actually, but i don't know how much i want to
patch/diverge from upstream, even though they'd probably be a few small
patches.
Most of what i'd like to see is gtk2 going away, even though gtk3
support is "experimental" it works much better than gtk2 according to my
tests, and having both in the target sucks.
The leftover mandatory gtk2 support is for binary netscape api plugins,
which outside of x86* (flash) it probably doesn't make any sense.

> Aah, that's how you solved the infinite loop.

Magic!
I've found this build-testing in an old debian chroot and worked it out
the quick way (well, not so quick for people building in such a scenario).
For webkit-gtk 2.6.x+ it's probably solved via the cmake migration.

> And why? :-)

Thin archives break the build, though i must admit i don't recall
exactly how (it was at the very start of the cleanup effort).

>> +WEBKITGTK24_CONF_OPTS = \
>> +	--enable-dependency-tracking \
> 
> Why? Yes it is in the older webkit, but do we have a reason to have it
> here?

Makefile logic doesn't parallelize well: it breaks the build usually
when building WTF (at the beginning).
It might be worth adding a comment.

Most of the build breakage is solved in the newer versions with cmake,
but midori doesn't like that.

Regards.