[Webkit-unassigned] [Bug 146680] Replace OpenGL{, ES}Shims with libepoxy, and #if USE(OPENGL_ES_2) with runtime checks

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=146680

--- Comment #12 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #9)
> The intent behind the policy (at least, my intent) is to not introduce
> dependencies that are too new for our target distros. Adding a new
> dependency that already exists in both target distros (Ubuntu 14.04, Debian
> Jessie), which will not cause any build problems, seems fine to me.
> 
> Ubuntu 14.04 has libepoxy 1.1, so we can add a dependency on that. If we
> want to add a dependency on libepoxy 1.2, then we'd need to wait until next
> April, when our target switches from Ubuntu 14.04 to Ubuntu 16.04.
> 
> (In reply to comment #8)
> > GTK+ already depended on libepoxy (since 3.18 i believe). So it will not be
> > a real new dependency at least for WebKitGTK+. But I understand the concern
> > for other ports. Would this patch implement something that will be used for
> > WebKitGTK+ or it will be shared with other ports?
> 
> And, in particular, what other ports? If it's just EFL, they target Ubuntu;
> I strongly suspect they would be happy to use system libepoxy. If it would
> be needed for any Apple ports, then it needs to be bundled. I'm not sure
> about WinCairo.

GTK+, EFL and Windows. I'm not sure about mac.

> From a downstream perspective: if you bundle libepoxy, we will rm -rf it in
> our spec file and patch the build to use system libepoxy. I suspect Berto
> will want something similar. So it would be greatly preferred to not bundle
> it, or to use the bundled version only for other ports if required and not
> distribute it with WebKitGTK+.

I don't like adding projects to ThirdParty either, but sometimes there's no other way if we need to add a new dependency that is mandatory. Using libepoxy conditionally doesn't make sense, I think.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160906/98b044b9/attachment.html>