GNOME Bugzilla – Bug 760439
Merge clutter and cogl forks into mutter
Last modified: 2016-04-29 14:49:06 UTC
Having cogl and clutter separate from mutter while still being two core building stones is creating unnecessary difficulties. For example, for making cogl and clutter support features that will only ever be relevant to a compositor (for example multi DPI rendering or fake input devices) having to add support (even incomplete support) to all available backends that must be supported doesn't seem like a reasonable requirement. Other problems is that we have a public/half stable API (API changes are possible, but annoying) making it hard to add other features that require tighter coupling of rendering, KMS interaction, input devices/events etc. Therefore I formally propose to fork cogl and clutter, merging those forks into the mutter repository. There are many ways of doing this. Some time ago I attempted this with clutter, and did this by simply copying the files and relevant backends into mutter/clutter, added a new Makefile.am building "libmutter-clutter.so" that was referenced from mutter's toplevel Makefile.am. GNOME Shell was changed to link against libmutter-clutter.so instead of libclutter.so. Other, probably better, approaches may include preparing cogl.git and clutter.git forks, stripping away anything not in the clutter/ or cogl/ directories either using history rewrite or just git-rm, and merging them into mutter.git adding the necessary new build files etc. In any way, what would be done initially is removal of all irrelevant backends (win32, macosx, gdk, probably also wayland), and maybe other features not relevant. After that it would be a lot easier to do any relevant refactorizations that were previously a lot harder, while being able to provide more compositor related API without having to caring too much about backward compatibility. What would be needed is probably some way to guard against accidentally linking libclutter.so after this as well. This change has been under discussion for quite some time. I discussed it with ebassi at GUADEC last year and he was positive to the idea, and if I can get a +1 from enough people, I'll go ahead and prepare a branch. Comments?
I'm tentatively positive on this. My main concern is alterations of the core API for development purposes; given that Mutter and the Shell would now use an internal copy of Cogl and Clutter, people trying to use the Clutter API as published on developer.gnome.org may end up hitting one of the changes and not understand the difference. Obviously, the better option would be to take the Cogl and Clutter forks and rename them, but that would break every single extension - even the ones we maintain as part of GNOME Classic.
There is an alternative approach which would avoid the fork + clone, but I haven't thought about its feasibility. We could deprecate/neuter most of the Cogl API, and move the KMS/eglnative code from Mutter to Cogl. I could also add escape hatches to the Clutter API that would allow you to set up Cogl outputs, framebuffers, and contexts from an external source, and have them replace the ones that Clutter creates at initialization time. I kinda want this for reusing GdkGLContext in the Clutter GDK backend. Again: it's a 5 minutes idea that I haven't carefully validated or even deeply thought about, but I wanted to throw it on the pile.
(In reply to Emmanuele Bassi (:ebassi) from comment #1) > I'm tentatively positive on this. > > My main concern is alterations of the core API for development purposes; > given that Mutter and the Shell would now use an internal copy of Cogl and > Clutter, people trying to use the Clutter API as published on > developer.gnome.org may end up hitting one of the changes and not understand > the difference. I think the reasonable thing would be to not change any existing stable protocol used by extensions etc. The main benefit is to make it easier to add additional API that is only relevant for compositors and internal refactorizations that reflect such API. > > Obviously, the better option would be to take the Cogl and Clutter forks and > rename them, but that would break every single extension - even the ones we > maintain as part of GNOME Classic. I think this is something that could be one alternative for GNOME 4. (In reply to Emmanuele Bassi (:ebassi) from comment #2) > There is an alternative approach which would avoid the fork + clone, but I > haven't thought about its feasibility. > > We could deprecate/neuter most of the Cogl API, and move the KMS/eglnative > code from Mutter to Cogl. I could also add escape hatches to the Clutter API > that would allow you to set up Cogl outputs, framebuffers, and contexts from > an external source, and have them replace the ones that Clutter creates at > initialization time. I kinda want this for reusing GdkGLContext in the > Clutter GDK backend. I think moving KMS from mutter to cogl is the wrong direction. To have them as separate libraries with separate releases and API promises is just not good at this point. If I could, I would move the whole KMS cogl backend into mutter not having any KMS in cogl at all. > > Again: it's a 5 minutes idea that I haven't carefully validated or even > deeply thought about, but I wanted to throw it on the pile.
i'm playing around with merging clutter/cogl into mutter now. So far I've got clutter lobbed into the mutter tree here (not yet tested): https://github.com/halfline/mutter/tree/wip/merge-clutter-cogl (can't put it on git.gnome.org without sysadmin help since clutter has so old commits that don't pass today's git sanity checks) I'm going to do cogl next, then test it just to prototype it out. my motivation is i want to consolidate the drm goo in one place. The current interface between mutter and cogl for doing monitor setup and such is really icky. Also, the cogl kms winsys and mutter do things behind each others back. We could also achieve that goal by allowing external cogl winsys implementations, or by having an "external" winsys that has a smaller exported abstraction of the winsys functions, but, as I understand it, cogl isn't really maintained and has a bunch of code nobody is using anymore, so it's easier to just move it all into mutter. The only reason I care about clutter, personally, is just because it's in between the two, but I guess having it in tree will be useful for reasons jonas alluded to in comment 0.
(In reply to Ray Strode [halfline] from comment #4) > i'm playing around with merging clutter/cogl into mutter now. > > So far I've got clutter lobbed into the mutter tree here (not yet tested): > > https://github.com/halfline/mutter/tree/wip/merge-clutter-cogl > Nice! I wounder though, will git gracefully handle merging commits (assuming you fix conflicts) from clutter, if you moved clutter/clutter to clutter/clutter/clutter? > (can't put it on git.gnome.org without sysadmin help since clutter has so > old commits that don't pass today's git sanity checks) > > I'm going to do cogl next, then test it just to prototype it out. my > motivation is i want to consolidate the drm goo in one place. The current > interface between mutter and cogl for doing monitor setup and such is really > icky. Also, the cogl kms winsys and mutter do things behind each others > back. > > We could also achieve that goal by allowing external cogl winsys > implementations, or by having an "external" winsys that has a smaller > exported abstraction of the winsys functions, but, as I understand it, cogl > isn't really maintained and has a bunch of code nobody is using anymore, so > it's easier to just move it all into mutter. The only reason I care about > clutter, personally, is just because it's in between the two, but I guess > having it in tree will be useful for reasons jonas alluded to in comment 0. Allowing external winsys seems to be a good approach to me. We should consider doing the same for clutter, i.e. moving the libinput, eglnative and maybe even the x11 backend into Meta* objects.
Hi, > Nice! I wounder though, will git gracefully handle merging commits (assuming > you fix conflicts) from clutter, if you moved clutter/clutter to > clutter/clutter/clutter? Do you mean mutter/clutter/clutter ? Let me rephrase your question, because i'm not entirely sure I follow. You tell me if I got it right: After heavily pruning clutter and bundling it into a subdirectory of the mutter tree (and using recursive configure), the original clutter codebase will likely continue to get fixes. We will likely be interested in picking those changes up. Does git have a story for merging those changes back to the fork? If that's your question, then I think the answer is we would need a parallel branch in clutter (say clutter-1.26-for-mutter) that would have all the pruning changes in it, and we would merge back clutter-1.26 with the subtree merge strategy or something like that. Another approach would be to skip the recursive configure and just merge the two configure's together, so we end up with clutter/clutter → mutter/clutter instead of clutter/clutter → mutter/clutter/clutter that would be more integrated and less bolted on, also, so maybe that's the better way to go, not sure. > Allowing external winsys seems to be a good approach to me. We should > consider doing the same for clutter, i.e. moving the libinput, eglnative and > maybe even the x11 backend into Meta* objects. Of course, there's no reason we couldn't make those apis public in clutter/cogl without forking. I think in many cases it's just removing leading underscores. We could throw them into a libclutterprivate / libcoglprivate or whatever to keep them out of the main api. Still, let me finish up this prototype and we can use it as a bit of playground, and then we can decide which direction we want to go.
(In reply to Ray Strode [halfline] from comment #6) > Hi, > > > Nice! I wounder though, will git gracefully handle merging commits (assuming > > you fix conflicts) from clutter, if you moved clutter/clutter to > > clutter/clutter/clutter? > Do you mean mutter/clutter/clutter ? > Yes. > Let me rephrase your question, because i'm not entirely sure I follow. You > tell me if I got it right: > > After heavily pruning clutter and bundling it into a subdirectory of the > mutter tree (and using recursive configure), the original clutter codebase > will likely continue to get fixes. We will likely be interested in picking > those changes up. Does git have a story for merging those changes back to > the fork? > > If that's your question, then I think the answer is we would need a parallel > branch in clutter (say clutter-1.26-for-mutter) that would have all the > pruning changes in it, and we would merge back clutter-1.26 with the subtree > merge strategy or something like that. I don't think that'd be needed though? If the branch merged into mutter is coming from a clutter clone, it'd be the same as backporting commits directly from clutter. I assume one would just need to have a clutter remote added to the mutter repo. The question was rather, does the fact that the clutter/clutter directory was moved to mutter/clutter/clutter cause git to fail merging patches? > > Another approach would be to skip the recursive configure and just merge the > two configure's together, so we end up with clutter/clutter → mutter/clutter > instead of clutter/clutter → mutter/clutter/clutter that would be more > integrated and less bolted on, also, so maybe that's the better way to go, > not sure. This is how I did it (except in my experiment I didn't bother with the git history, as I just wanted to test if there was any problems with the building and linking etc). I pushed that attempt here if you want to have a look: https://github.com/jadahl/mutter/commits/wip/intree-clutter > > > Allowing external winsys seems to be a good approach to me. We should > > consider doing the same for clutter, i.e. moving the libinput, eglnative and > > maybe even the x11 backend into Meta* objects. > Of course, there's no reason we couldn't make those apis public in > clutter/cogl without forking. I think in many cases it's just removing > leading underscores. We could throw them into a libclutterprivate / > libcoglprivate or whatever to keep them out of the main api. Still, let me > finish up this prototype and we can use it as a bit of playground, and then > we can decide which direction we want to go. Yea, the API additions etc can of course be done without forking. Those changes are only made easier with forking. I'd say the main reason for forking is that we shouldn't need to mess with all the backends for doing required refactorizations. The fact that it becomes easier to do external winsys backends etc is a nice bonus.
just a note here that I haven't forgotten about this, I want to get back to it soon.
So I've been pretty slow on this and Rui mentioned he potentially wants to work on it, so I told him I would post the latest things I've got. Latest work on merging clutter in is here (still untested, but it builds): https://github.com/halfline/mutter/tree/wip/merge-clutter-cogl (again, we'll need to talk to gnome sysadmins when we do the final merge because of some artifacts in the clutter history) I started to pare down cogl in preparation to merge it here (this still needs a bit of work): https://git.gnome.org/browse/cogl/log/?h=rstrode/wip/prepare-for-mutter-merge I started to unthread cogl from kms a bit here: https://git.gnome.org/browse/mutter/log/?h=halfline/wip/kms-cleanups
Hi, it took a while but I finally have something that works: https://github.com/rtcm/mutter contains trimmed down cogl/ and clutter/ subdirectories based on Ray's initial work in comment 9. I had to massage it a bit to keep all the history and remain buildable on every step. All the binaries and typelibs are installed under $libdir/mutter/ . I had to make it install headers (under $includedir/mutter/) and (renamed) .pc files too so that gnome-shell remains buildable with little modifications. There's only a small commit needed: https://git.gnome.org/browse/gnome-shell/commit/?h=wip/rtcm/merge&id=389539d1a02d9ff1301c896df9254daa962e5224 Please try it out and let me know if you'd like to see something done differently.
I force updated the mutter branch to fix the build with builddir != srcdir and make dist work.
I have a few questions/comments. Overall I think it looks great. I'm wondering is whether we really should drop support for GLES (as is done according to at least a commit subject of 3f9583ce158a44432bf75c2cfa3de4cc715d2043). Are we not eventually targeting running on ARM devices for example? I'm assuming those won't support "desktop" OpenGL. When we generate the .gir files, we should probably not call them Clutter-1.0.gir etc, but rather MutterClutter.gir or something. Same for cogl. Should we also install these and make gnome-shell use them, as they'll technically be using the new cogl/clutter .so files? What type of stability promises should we make? gnome-shell is not the only libmutter user, so we can't really go and change the actor API for example. What parts should we declare stable? We could for example keep all the actor API stable, and declare the rest to be in anarchy, but what about input devices, input device manager etc? While much less urgent, it wouldn't hurt to bisect that API apart either, but maybe it can wait for "GNOME 4". Another thing I noticed, which I suppose doesn't matter much, and it might just be git playing tricks no me, is that the "merge clutter into mutter" seems to actually be a merge of mutter into clutter.
(In reply to Jonas Ådahl from comment #12) > I have a few questions/comments. Overall I think it looks great. > > I'm wondering is whether we really should drop support for GLES (as is done > according to at least a commit subject of > 3f9583ce158a44432bf75c2cfa3de4cc715d2043). Are we not eventually targeting > running on ARM devices for example? I'm assuming those won't support > "desktop" OpenGL. We do want GLES support. That's what Endless use for one of their machines, and we just added GLES support to gnome-session's accelerated checks and gnome-control-center's Details panel.
(In reply to Bastien Nocera from comment #13) > (In reply to Jonas Ådahl from comment #12) > > I have a few questions/comments. Overall I think it looks great. > > > > I'm wondering is whether we really should drop support for GLES (as is done > > according to at least a commit subject of > > 3f9583ce158a44432bf75c2cfa3de4cc715d2043). Are we not eventually targeting > > running on ARM devices for example? I'm assuming those won't support > > "desktop" OpenGL. > > We do want GLES support. That's what Endless use for one of their machines, > and we just added GLES support to gnome-session's accelerated checks and > gnome-control-center's Details panel. On the other hand, Endless does not rebase Mutter and the Shell that often, and a radical reimplementation of the code base like this one could push a rebase farther in the future. While we want GLES support for some of our products, maybe this is a good chance to make the GLES support smaller than the full-on API inside Cogl.
Is there a problem with just keeping the GLES support in for now ?
> When we generate the .gir files, we should probably not call them > Clutter-1.0.gir etc, but rather MutterClutter.gir or something. Same for > cogl. Should we also install these and make gnome-shell use them, as they'll > technically be using the new cogl/clutter .so files? I think they should be installed in /usr/lib64/mutter and shadow the out of tree clutter/cogl for just gnome-shell/mutter. They should probably keep the same names at least short term or we're going to need to fix gnome-shell and all the extensions to use the new names in one go which would be less than pleasant. > What type of stability promises should we make? gnome-shell is not the only > libmutter user, so we can't really go and change the actor API for example. > What parts should we declare stable? I don't think we've ever treated libmutter as stable have we? I mean we've transformed it from a binary that loads plugins to a library before. We also routinely update the api between mutter and gnome-shell.
While there is no official stability promise, I have tried to keep the ABI changes to a minimum out of politeness to downstream consumers.
(In reply to Jonas Ådahl from comment #12) > I'm wondering is whether we really should drop support for GLES (as is done > according to at least a commit subject of > 3f9583ce158a44432bf75c2cfa3de4cc715d2043). Are we not eventually targeting > running on ARM devices for example? I'm assuming those won't support > "desktop" OpenGL. Ok, I re-worked the branch to keep GLES support in. > When we generate the .gir files, we should probably not call them > Clutter-1.0.gir etc, but rather MutterClutter.gir or something. Same for > cogl. Should we also install these and make gnome-shell use them, as they'll > technically be using the new cogl/clutter .so files? Changing the typelib file names means we'd need to change all gnome-shell's JS files to import the changed name. Then shell extensions would have to be updated too. I don't think we need to go through that pain since the typelib files are installed in $libdir/mutter and thus shouldn't conflict with anything. One thing we could do is instead of installing libmutter-clutter.so etc. we link everything into libmutter.so (while still keeping the typelib files as they are) . Yes/no? > Another thing I noticed, which I suppose doesn't matter much, and it might > just be git playing tricks no me, is that the "merge clutter into mutter" > seems to actually be a merge of mutter into clutter. Yeah, I had the merge done the other way around. Fixed it now
Any more feedback on this, or are we ready to figure out the technicalities of getting this on git.gnome.org and merged ?
(In reply to Rui Matos from comment #18) > (In reply to Jonas Ådahl from comment #12) > > I'm wondering is whether we really should drop support for GLES (as is done > > according to at least a commit subject of > > 3f9583ce158a44432bf75c2cfa3de4cc715d2043). Are we not eventually targeting > > running on ARM devices for example? I'm assuming those won't support > > "desktop" OpenGL. > > Ok, I re-worked the branch to keep GLES support in. > > > When we generate the .gir files, we should probably not call them > > Clutter-1.0.gir etc, but rather MutterClutter.gir or something. Same for > > cogl. Should we also install these and make gnome-shell use them, as they'll > > technically be using the new cogl/clutter .so files? > > Changing the typelib file names means we'd need to change all gnome-shell's > JS files to import the changed name. Then shell extensions would have to be > updated too. I don't think we need to go through that pain since the typelib > files are installed in $libdir/mutter and thus shouldn't conflict with > anything. How can we be sure the extensions etc use the files from $libdir/mutter and not the "real" ones? Are the added include paths to introspection scanner prioritized before the system ones? > > One thing we could do is instead of installing libmutter-clutter.so etc. we > link everything into libmutter.so (while still keeping the typelib files as > they are) . Yes/no? This could work, but how exactly would it help?
(In reply to Jonas Ådahl from comment #20) > How can we be sure the extensions etc use the files from $libdir/mutter and > not the "real" ones? Are the added include paths to introspection scanner > prioritized before the system ones? gnome-shell has always prioritized $libdir/mutter and $libdir/gnome-shell when looking for typelibs. From gnome-shell's main.c: static void shell_introspection_init (void) { g_irepository_prepend_search_path (MUTTER_TYPELIB_DIR); g_irepository_prepend_search_path (GNOME_SHELL_PKGLIBDIR); } > > One thing we could do is instead of installing libmutter-clutter.so etc. we > > link everything into libmutter.so (while still keeping the typelib files as > > they are) . Yes/no? > > This could work, but how exactly would it help? This was a poorly worded unrelated suggestion, sorry. It's just something we can do to reduce the amount of shared libraries we install.
(In reply to Rui Matos from comment #21) > (In reply to Jonas Ådahl from comment #20) > > How can we be sure the extensions etc use the files from $libdir/mutter and > > not the "real" ones? Are the added include paths to introspection scanner > > prioritized before the system ones? > > gnome-shell has always prioritized $libdir/mutter and $libdir/gnome-shell > when looking for typelibs. From gnome-shell's main.c: > > static void > shell_introspection_init (void) > { > g_irepository_prepend_search_path (MUTTER_TYPELIB_DIR); > g_irepository_prepend_search_path (GNOME_SHELL_PKGLIBDIR); > } > Fair enough! I don't have any more concerns right now. Post merge, I think we can also remove the clutter Wayland backend. The cogl-as-a-wayland-client support was as far as I can see removed, so it wouldn't work anyway. If we want to support running mutter nested on top of Wayland, we can reconsider how to do that then.
(In reply to Jonas Ådahl from comment #22) > (In reply to Rui Matos from comment #21) > > (In reply to Jonas Ådahl from comment #20) > > > How can we be sure the extensions etc use the files from $libdir/mutter and > > > not the "real" ones? Are the added include paths to introspection scanner > > > prioritized before the system ones? > > > > gnome-shell has always prioritized $libdir/mutter and $libdir/gnome-shell > > when looking for typelibs. From gnome-shell's main.c: > > > > static void > > shell_introspection_init (void) > > { > > g_irepository_prepend_search_path (MUTTER_TYPELIB_DIR); > > g_irepository_prepend_search_path (GNOME_SHELL_PKGLIBDIR); > > } > > > > Fair enough! I don't have any more concerns right now. Post merge, I think > we can also remove the clutter Wayland backend. The cogl-as-a-wayland-client > support was as far as I can see removed, so it wouldn't work anyway. If we > want to support running mutter nested on top of Wayland, we can reconsider > how to do that then. Running nested used to work ... which is also useful for development / debugging.
(In reply to drago01 from comment #23) > (In reply to Jonas Ådahl from comment #22) > > (In reply to Rui Matos from comment #21) > > > (In reply to Jonas Ådahl from comment #20) > > > > How can we be sure the extensions etc use the files from $libdir/mutter and > > > > not the "real" ones? Are the added include paths to introspection scanner > > > > prioritized before the system ones? > > > > > > gnome-shell has always prioritized $libdir/mutter and $libdir/gnome-shell > > > when looking for typelibs. From gnome-shell's main.c: > > > > > > static void > > > shell_introspection_init (void) > > > { > > > g_irepository_prepend_search_path (MUTTER_TYPELIB_DIR); > > > g_irepository_prepend_search_path (GNOME_SHELL_PKGLIBDIR); > > > } > > > > > > > Fair enough! I don't have any more concerns right now. Post merge, I think > > we can also remove the clutter Wayland backend. The cogl-as-a-wayland-client > > support was as far as I can see removed, so it wouldn't work anyway. If we > > want to support running mutter nested on top of Wayland, we can reconsider > > how to do that then. > > Running nested used to work ... which is also useful for development / > debugging. Running nested uses the X11 backend. When running from a Wayland session, it runs nested via Xwayland.
(In reply to Jonas Ådahl from comment #24) > (In reply to drago01 from comment #23) > > (In reply to Jonas Ådahl from comment #22) > > > (In reply to Rui Matos from comment #21) > > > > (In reply to Jonas Ådahl from comment #20) > > > > > How can we be sure the extensions etc use the files from $libdir/mutter and > > > > > not the "real" ones? Are the added include paths to introspection scanner > > > > > prioritized before the system ones? > > > > > > > > gnome-shell has always prioritized $libdir/mutter and $libdir/gnome-shell > > > > when looking for typelibs. From gnome-shell's main.c: > > > > > > > > static void > > > > shell_introspection_init (void) > > > > { > > > > g_irepository_prepend_search_path (MUTTER_TYPELIB_DIR); > > > > g_irepository_prepend_search_path (GNOME_SHELL_PKGLIBDIR); > > > > } > > > > > > > > > > Fair enough! I don't have any more concerns right now. Post merge, I think > > > we can also remove the clutter Wayland backend. The cogl-as-a-wayland-client > > > support was as far as I can see removed, so it wouldn't work anyway. If we > > > want to support running mutter nested on top of Wayland, we can reconsider > > > how to do that then. > > > > Running nested used to work ... which is also useful for development / > > debugging. > > Running nested uses the X11 backend. When running from a Wayland session, it > runs nested via Xwayland. Ah indeed. So yeah we can / should remove the clutter wayland backend then.
(In reply to Jonas Ådahl from comment #22) > Post merge, I think > we can also remove the clutter Wayland backend. The cogl-as-a-wayland-client > support was as far as I can see removed, so it wouldn't work anyway. I removed that now too. And the branch has been pushed to git.gnome.org (still named wip/rtcm/merge) with av's help. What's the way forward? I think we could merge it to master and release 3.21.1 with it as is. But we can also wait and merge right after this week's devel release.
(In reply to Rui Matos from comment #26) > What's the way forward? I think we could merge it to master and release > 3.21.1 > with it as is. But we can also wait and merge right after this week's devel > release. I'd be fine with either of those options.
I pushed the merge to master now and Florian will release 3.21.1 with it. I think we can close this and continue working on the bugs this one blocked.
mutter no longer builds without wayland: $ ./configure --enable-maintainer-mode --prefix /home/lantw44/gnome/devinstall --enable-compile-warnings=maximum --enable-installed-tests --disable-wayland-egl-server --disable-static --enable-gtk-doc ... checking for CLUTTER_DEPS... no configure: error: Package requirements (cairo-gobject >= 1.14.0 gio-2.0 >= 2.44.0 atk >= 2.5.3 pangocairo >= 1.30 json-glib-1.0 >= 0.12.0 wayland-egl wayland-server libdrm gbm x11 xext xdamage xcomposite >= 0.4 xi) were not met: Package wayland-egl was not found in the pkg-config search path. Perhaps you should add the directory containing `wayland-egl.pc' to the PKG_CONFIG_PATH environment variable Package 'wayland-egl', required by 'world', not found Package 'wayland-server', required by 'world', not found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables CLUTTER_DEPS_CFLAGS and CLUTTER_DEPS_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. configure: error: ./configure failed for clutter
Honestly I'd prefer that we finally make wayland a non-optional dependency. What do others think?
(In reply to Rui Matos from comment #30) > Honestly I'd prefer that we finally make wayland a non-optional dependency. > What do others think? I hope this can only happen after FreeBSD and OpenBSD get Wayland support.
Rui, how hard would it be to keep non-wayland builds working ?
Created attachment 326969 [details] [review] clutter: Add back support for non-wayland builds Wayland support is only available on Linux, so keep it optional for now. Does this patch work? I went with a single --disable-wayland-egl-server flag as in cogl, no need to add back the different backend/input-backend flags that standalone clutter uses ...
(In reply to Florian Müllner from comment #33) > Created attachment 326969 [details] [review] [review] > clutter: Add back support for non-wayland builds > > Wayland support is only available on Linux, so keep it optional for > now. > > Does this patch work? I went with a single --disable-wayland-egl-server flag > as in cogl, no need to add back the different backend/input-backend flags > that standalone clutter uses ... No, it still needs libudev and libinput. checking for CLUTTER_DEPS_PRIVATE... no configure: error: Package requirements ( pangoft2 libudev >= 136 libinput >= 0.19.0 xkbcommon) were not met: Package libudev was not found in the pkg-config search path. Perhaps you should add the directory containing `libudev.pc' to the PKG_CONFIG_PATH environment variable Package 'libudev', required by 'world', not found Package 'libinput', required by 'world', not found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables CLUTTER_DEPS_PRIVATE_CFLAGS and CLUTTER_DEPS_PRIVATE_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. configure: error: ./configure failed for clutter
Created attachment 326988 [details] [review] clutter: Add back support for non-wayland builds
Review of attachment 326988 [details] [review]: If it works for those that need it, seems fine.
This still doesn't work: gmake[4]: Entering directory '/home/lantw44/gnome/source/mutter/clutter/clutter' (... a lot of unknown option warnings ...) CC x11/clutter-device-manager-xi2.lo warning: unknown warning option '-Werror=logical-op'; did you mean '-Werror=long-long'? [-Wunknown-warning-option] x11/clutter-device-manager-xi2.c:171:40: warning: cast from 'XIAnyClassInfo *' to 'XIKeyClassInfo *' increases required alignment from 4 to 8 [-Wcast-align] XIKeyClassInfo *key_info = (XIKeyClassInfo *) class_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ x11/clutter-device-manager-xi2.c:188:37: warning: cast from 'XIAnyClassInfo *' to 'XIValuatorClassInfo *' increases required alignment from 4 to 8 [-Wcast-align] (XIValuatorClassInfo *) class_info); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ x11/clutter-device-manager-xi2.c:194:46: warning: cast from 'XIAnyClassInfo *' to 'XIScrollClassInfo *' increases required alignment from 4 to 8 [-Wcast-align] XIScrollClassInfo *scroll_info = (XIScrollClassInfo *) class_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 warnings generated. CC x11/clutter-input-device-xi2.lo warning: unknown warning option '-Werror=logical-op'; did you mean '-Werror=long-long'? [-Wunknown-warning-option] 1 warning generated. CC cogl/clutter-stage-cogl.lo warning: unknown warning option '-Werror=logical-op'; did you mean '-Werror=long-long'? [-Wunknown-warning-option] 1 warning generated. CC evdev/clutter-xkb-utils.lo warning: unknown warning option '-Werror=logical-op'; did you mean '-Werror=long-long'? [-Wunknown-warning-option] 1 warning generated. CC wayland/clutter-wayland-surface.lo warning: unknown warning option '-Werror=logical-op'; did you mean '-Werror=long-long'? [-Wunknown-warning-option] In file included from wayland/clutter-wayland-surface.c:42: wayland/clutter-wayland-surface.h:34:10: fatal error: 'wayland-server.h' file not found #include <wayland-server.h> ^ 1 warning and 1 error generated. Makefile:1631: recipe for target 'wayland/clutter-wayland-surface.lo' failed gmake[4]: *** [wayland/clutter-wayland-surface.lo] Error 1
Created attachment 327026 [details] [review] clutter: Add back support for non-wayland builds Updated patch that has been confirmed working on IRC.
Review of attachment 327026 [details] [review]: ok
Attachment 327026 [details] pushed as 3856622 - clutter: Add back support for non-wayland builds