Re: [gtk-osx-devel] Bison 3 and WebKit




On Dec 22, 2014, at 9:11 AM, Philip Chimento <philip chimento gmail com> wrote:

On Mon, Dec 22, 2014 at 9:04 AM, John Ralls <jralls ceridwen us> wrote:

On Dec 21, 2014, at 9:09 PM, Philip Chimento <philip chimento gmail com> wrote:

On Tue, Dec 16, 2014 at 12:39 PM, John Ralls <jralls ceridwen us> wrote:

On Dec 16, 2014, at 12:25 AM, Philip Chimento <philip chimento gmail com> wrote:

On Mon, Dec 15, 2014 at 11:01 AM, John Ralls <jralls ceridwen us> wrote:

On Dec 14, 2014, at 10:14 PM, Philip Chimento <philip chimento gmail com> wrote:

On Mon, Dec 8, 2014 at 8:15 PM, John Ralls <jralls ceridwen us> wrote:

On Dec 8, 2014, at 3:37 PM, Philip Chimento <philip chimento gmail com> wrote:

On Sun, Dec 7, 2014 at 5:05 PM, John Ralls <jralls ceridwen us> wrote:
The upgrade of Bison to version 3 which you graciously provided breaks the WebKit build, which you 
also graciously provided. ISTR that you mumbled something about working on building a newer WebKit 
version. Are you?

Yes! It's been a bit pre-empted by other stuff, but I am still working on building WebKit 2.4.7. What 
is it about Bison 3 that breaks the old build?
[log]
Moving ~/.local/bin/bison out of the way, so that it uses the one Apple ships (v.2.3), clears the 
problem.

I've got something almost working for modulesets-stable on the update-webkit branch of 
ptomato/gtk-osx-build: https://github.com/ptomato/gtk-osx-build/tree/update-webkit

[...]

Also, if you're waiting on this module to be buildable again, I can submit a pull request that only 
updates modulesets-stable while I work on the other two modulesets.

[...]

I just deleted Bison 3 after bootstrapping, so it’s not holding anything up for me. That doesn’t help 
anyone who needs both gstreamer and WebKit, though. Maybe bison 2.7.1 would work for both.

[...]

I'd rather upgrade WebKit than downgrade Bison, although 2.7.1 would work for gstreamer; it needs 2.4 or 
later.

What’s the oldest version of OS X that WebKit 2.7 will build on/for? It looks like its CFLAGS include 
-std=c++11, so perhaps nothing earlier than 10.7 unless it can be made to work with gcc-4.8, which would 
have to be built separately from gtk-osx.

Good question. In light of that, should I perhaps keep the old WebKit 1.x module intact, and instead add a 
new one for webkitgtk 2.x? I might have to add a new one anyway since webkitgtk 2.x has discontinued the 
old WebKit 1 single-process API, and a lot of apps still depend on it. How about two new modules named 
webkit1gtk and webkit2gtk?

Yes, I think that would be wise.

How about just “webkit” and “webkit2” so that app modulesets don’t break gratuitously?

Actually what I meant was keeping the existing one, and adding two more. All the APIs and version numbers 
are confusing but here's everything I'm proposing in a nutshell:

- WebKit - WebKitGTK 1.x, WebKit 1 API, works with GTK 2.x (could be built for GTK 3.x but let's not bother)
- webkit1gtk - WebKitGTK 2.4.x, WebKit 1 API, works with GTK 3.x
- webkit2gtk - WebKitGTK >2.6, WebKit 2 API, works with GTK 3.x

I picked "webkit2gtk" because that's what the pkg-config file calls itself and "webkit1gtk" in analogy to 
that. (Actually webkit1gtk's pkg-config file is called "webkitgtk" so that might be better for consistency 
but a more confusing name.)

Ah, got it.

Could we use ‘webkit[12]gtk3’ to make it clear that they’re gtk3-only?

That aside, the only way to deal with the confusion is to comment each module with what it’s for.

Regards,
John Ralls



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]