Bug 120455

What version GTK+ are you planning to use?

I'm thinking of glib-2.37.3.tar.xz, gtk+-3.9.6.tar.xz and gdk-pixbuf-2.29.2.tar.xz at least. I'm using weston 1.0.5 on ubuntu 13.04. If we choose higher versions than those, we might need to build wayland-client and related stuff as well. So I think those versions are appropriate now. Any idea? :)

I'm using Wayland 1.0 and GTK+ 3.9.6 as well, like you, on Ubuntu 13.04. So that works for me. As you point out, the GTK+ 3.10 version will end up requiring Wayland 1.2, but I'd rather see this being addressed outside the Jhbuild modules (i.e. developers would have to move onto systems that provide Wayland 1.2 by default).

Created attachment 210069 [details] Patch

Comment on attachment 210069 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=210069&action=review I defer to Zan on the versions that should be used, though, and whether it makes sense to add wayland modules themselves. > Tools/gtk/jhbuild-optional.modules:50 > + <autotools id="glib-for-wayland" hmm, I think you should not use the -for-wayland suffix. These definitions should override the definitions in the main modules file instead - which makes sense, since they *will* be installed instead of/on top of the original ones.

I don't think it's practical to include the complete Wayland setup in the Jhbuild modules. If we agree on that, the version of the GTK+ dependency to use in this case depends on what version of Wayland we agree to proceed on using. I'd propose Wayland 1.2 since that's what GTK+ 3.10 will require and it would be a bit strange to provide a 3.9.x development release. OTOH I'd like to continue to use Ubuntu, but I'm not sure what Wayland version will be provided in 13.10 (at the moment it's 1.1.0).

I think going with gtk 3.9.6 and wayland 1.0 is fine for now, I don't think we need anything bleeding edge at this point? So the only problem where I'm concerned is with the names of the modules.

I think maybe Zan has a point here. Wayland isn't required to run layout tests and our jhbuild setup allows hooking in custom modulesets. Maybe we should just skip this for now. I don't really understand the necessity.

(In reply to comment #7) > I think going with gtk 3.9.6 and wayland 1.0 is fine for now, I don't think we need anything bleeding edge at this point? So the only problem where I'm concerned is with the names of the modules. The reason of the suffix '-for-waylaynd' is that the last defined module name is just chosen by jhbuild if there are two more same names of modules, but different versions though. I haven't found a better approach yet.. > I think maybe Zan has a point here. Wayland isn't required to run layout tests and our jhbuild setup allows hooking in custom modulesets. Maybe we should just skip this for now. I don't really understand the necessity. Yes you're right Martin. I have used this change with my local modulesets file which added to WEBKIT_EXTRA_MODULESETS. But I think providing a convenient and consistent way to set up wayland env would also be good to somebody who is interested in webkitgtk wayland support. I don't think this change hurts anything. :)

(In reply to comment #9) > (In reply to comment #7) > > I think going with gtk 3.9.6 and wayland 1.0 is fine for now, I don't think we need anything bleeding edge at this point? So the only problem where I'm concerned is with the names of the modules. > > The reason of the suffix '-for-waylaynd' is that the last defined module name is just chosen by jhbuild if there are two more same names of modules, but different versions though. I haven't found a better approach yet.. I got a clue about this. https://developer.gnome.org/jhbuild/3.2/jhbuild.html#cfg-moduleset It says "If a module with the same name is present in more than one moduleset, the last set listed takes priority". Thus.. we need to use different ids for the duplicated modules.

(In reply to comment #8) > I think maybe Zan has a point here. Wayland isn't required to run layout tests and our jhbuild setup allows hooking in custom modulesets. Maybe we should just skip this for now. I don't really understand the necessity. I was writing about the Wayland setup as in the complete Weston-producing stack, which could require libdrm and mesa as well. This was discussed as a possibility if we jump straight to supporting Wayland 1.2, but it's not really rational. Custom moduleset files would work for me as well.

(In reply to comment #6) > If we agree on that, the version of the GTK+ dependency to use in this case depends on what version of Wayland we agree to proceed on using. I'd propose Wayland 1.2 since that's what GTK+ 3.10 will require and it would be a bit strange to provide a 3.9.x development release. OTOH I'd like to continue to use Ubuntu, but I'm not sure what Wayland version will be provided in 13.10 (at the moment it's 1.1.0). FWIW, for Ubuntu 13.10 there's the GNOME 3 staging PPA that provides 3.10 packages along with Wayland and Weston 1.2. https://launchpad.net/~gnome3-team/+archive/gnome3-staging

(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #7) > > > I think going with gtk 3.9.6 and wayland 1.0 is fine for now, I don't think we need anything bleeding edge at this point? So the only problem where I'm concerned is with the names of the modules. > > > > The reason of the suffix '-for-waylaynd' is that the last defined module name is just chosen by jhbuild if there are two more same names of modules, but different versions though. I haven't found a better approach yet.. > > I got a clue about this. https://developer.gnome.org/jhbuild/3.2/jhbuild.html#cfg-moduleset > It says "If a module with the same name is present in more than one moduleset, the last set listed takes priority". > Thus.. we need to use different ids for the duplicated modules. But this makes no sense. Think about it: if you have the suffix and this module gets built first, then the installed gtk+ will be overwritten by the other one when it gets built - you lose. The modules in the "extra" file are defined (or should be if it's not happening) after the main file, precisely so you can override the modules, using the same name.

(In reply to comment #13) > But this makes no sense. Think about it: if you have the suffix and this module gets built first, then the installed gtk+ will be overwritten by the other one when it gets built - you lose. As I know, webkitgtk-testing-dependencies is always the first moduleset added to 'modules'. See http://trac.webkit.org/browser/trunk/Tools/gtk/jhbuildrc#L34. So the suffixed gtk+ can not be build a head of original gtk+ in jhbuild.modules > The modules in the "extra" file are defined (or should be if it's not happening) after the main file, precisely so you can override the modules, using the same name. Yes we can override the original modules in jhbuild.modules by adding new modules in the extra file. But the problem here is that it's 'uncontidional'. If you set a extra file which defines gtk+3.9.6 with the module name 'gtk+' to WEBKIT_EXTRA_MODULESETS. then you can see gtk+ 3.9.6 will always be build even though you did't set "wayland-dependencies" to WEBKIT_EXTRA_MODULES. This is because the last defined module is chosen by jhbuild when same module names are present as I told you. Even though we add gtk+3.9.6 in jhbuild-optional.module with a same name like 'gtk+'. it would be ignored since the 'gtk+(3.6.0) in jhbuild.modules is defined later than that. See also http://trac.webkit.org/browser/trunk/Tools/gtk/jhbuild.modules#L35

(In reply to comment #14) > (In reply to comment #13) > > But this makes no sense. Think about it: if you have the suffix and this module gets built first, then the installed gtk+ will be overwritten by the other one when it gets built - you lose. > > As I know, webkitgtk-testing-dependencies is always the first moduleset added to 'modules'. See http://trac.webkit.org/browser/trunk/Tools/gtk/jhbuildrc#L34. > So the suffixed gtk+ can not be build a head of original gtk+ in jhbuild.modules > > > The modules in the "extra" file are defined (or should be if it's not happening) after the main file, precisely so you can override the modules, using the same name. > > Yes we can override the original modules in jhbuild.modules by adding new modules in the extra file. But the problem here is that it's 'uncontidional'. If you set a extra file which defines gtk+3.9.6 with the module name 'gtk+' to WEBKIT_EXTRA_MODULESETS. then you can see gtk+ 3.9.6 will always be build even though you did't set "wayland-dependencies" to WEBKIT_EXTRA_MODULES. This is because the last defined module is chosen by jhbuild when same module names are present as I told you. > Even though we add gtk+3.9.6 in jhbuild-optional.module with a same name like 'gtk+'. it would be ignored since the 'gtk+(3.6.0) in jhbuild.modules is defined later than that. See also http://trac.webkit.org/browser/trunk/Tools/gtk/jhbuild.modules#L35 With above reasons. We may eventually have three options to support wayland dependencies build. (Of course we have consensus on the necessity of this change.. :p) 1. Upversion of gtk+, glib+, gdk-pixbuf in jhbuild.modules accroding to the wayland requirement. 2. Add the dependencies with different module names to jhbuild-optional.modules 3. Add '--wayland' option to update-webkitgtk-lib and seperate out the duplicated libraries in jhbuild.modules into several files. Then we can choose a proper gtk+, glib and gdk-pixbuf conditionally. But I think it's a little excessive..

(In reply to comment #14) > (In reply to comment #13) > > But this makes no sense. Think about it: if you have the suffix and this module gets built first, then the installed gtk+ will be overwritten by the other one when it gets built - you lose. > > As I know, webkitgtk-testing-dependencies is always the first moduleset added to 'modules'. See http://trac.webkit.org/browser/trunk/Tools/gtk/jhbuildrc#L34. > So the suffixed gtk+ can not be build a head of original gtk+ in jhbuild.modules Yes… and like you said yourself, if modules with the same name are defined, the last one is used. There is no reason to use a different name. See? The system was designed with this case in mind. Believe me, I use *exactly* this here in my system for my Epiphany development environment - I override the versions of glib, gdk-pixbuf and gtk+ with git master. Or if you don't believe me, just try for yourself and you will see =) (In reply to comment #15) > With above reasons. We may eventually have three options to support wayland dependencies build. (Of course we have consensus on the necessity of this change.. :p) None of the 3 options is good. Just add the required versions with the same name. That should work, if it does not work we need to fix the jhbuild stuff, not work-around the bug (but I see no reason it would not work).

Created attachment 210791 [details] example: my extra moduleset This is the jhbuild modules file I use for my Epiphany dev environment.

Created attachment 210793 [details] example: the script I use to automate using my Epiphany dev environment This is the script I use when developing/testing epiphany, you can see how the environment variables are set up so that the extra moduleset is properly picked up.

Still not sure I understand the benefit of using JHBuild to install Wayland dependencies. They are not needed for the default testing environment. I'm not sure the JHBuild should try to support every possible configuration. If there's some reason why a Wayland compiled outside JHBuild won't work with build-webkit, then perhaps...

I guess it makes sense because Wayland is where we want to go - it is bound to become our default configuration at some point, so it makes sense to make it easy to hack on. So in a way it's similar to the libsecret case - it doesn't belong in our main jhbuild moduleset, but it goes into the optional moduleset so it's more convenient for developers.

(In reply to comment #20) > I guess it makes sense because Wayland is where we want to go - it is bound to become our default configuration at some point, so it makes sense to make it easy to hack on. So in a way it's similar to the libsecret case - it doesn't belong in our main jhbuild moduleset, but it goes into the optional moduleset so it's more convenient for developers. Okay. I'm not super opposed, but the fact that it requires using versions of requirements (breaking tests) seems odd. It could also be posted on the wiki with instructions for patching it into the JHBuild.

I think having a jhbuild-wayland.modules would make it special-cased enough to not break tests by mistake for people who are not developing?

A separate jhbuild-wayland.modules file, located in the tree, sounds best to me as well.

(In reply to comment #23) > A separate jhbuild-wayland.modules file, located in the tree, sounds best to me as well. Sounds like an excellent compromise to me as well.

(In reply to comment #24) > (In reply to comment #23) > > A separate jhbuild-wayland.modules file, located in the tree, sounds best to me as well. > > Sounds like an excellent compromise to me as well. Finally, we made a decision. \o/ O.K Let me go forward.

Created attachment 211166 [details] Patch

Comment on attachment 211166 [details] Patch LGTM, thanks! Would be good to have this information on the wiki so it's more discoverable, btw.

(In reply to comment #27) > (From update of attachment 211166 [details]) > LGTM, thanks! Would be good to have this information on the wiki so it's more discoverable, btw. O.K. Will do!

Comment on attachment 211166 [details] Patch Clearing flags on attachment: 211166 Committed r155610: <http://trac.webkit.org/changeset/155610>

All reviewed patches have been landed. Closing bug.