=== chihchun_afk is now known as chihchun
[08:31] <alan_g> greyback: does this work on zesty? https://code.launchpad.net/~alan-griffiths/miral/fix-for-zesty-gtest/+merge/312018
[08:32] <greyback> let me try
[08:32] <duflu> alan_g, greyback: You might want to link that to bug 1644062
[08:32] <ubot5`> bug 1644062 in content-hub (Ubuntu) "googletest 1.8.0-2 (on zesty) breaks existing builds [add_library cannot create target "gmock" ...]" [Critical,In progress] https://launchpad.net/bugs/1644062
=== JanC is now known as Guest13710
=== JanC_ is now known as JanC
[08:35] <alan_g> duflu: that looks like a different issue with the gtest changes
[08:35] <duflu> alan_g: It's the same thing. RAOF made the same fix as yours in his branch
[08:35] <duflu> Although the bug title would make you think not
[08:36] <alan_g> and the bug description. (And yes, I stole his approach)
[08:36] <greyback> alan_g: no luck: http://pastebin.ubuntu.com/23552386/
[08:36] <duflu> And I spent most of a day fixing that one and others related to gtest 1.8 last week
[08:38] <alan_g> greyback: can you check if HAS_W_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS is getting set?
[08:39] <greyback> alan_g: it's not getting set
[08:41] <alan_g> greyback: ack. I wonder why
[08:42] <greyback> I'll have a look
[08:43] <duflu> Does anyone apart from Xmir use mir_buffer_stream_swap_buffers (i.e. asynchronous swap callbacks)?
[08:45] <anpok_> duflu: i was tinkering with it in gtk
[08:45] <anpok_> in conjunction with the gdk frame clock
[08:45] <anpok_> but iirc that part has not landed yet
[08:45] <duflu> Ha. mir::client::FrameClock is the name of the class I'm working on
[08:45] <anpok_> .. yes it has not
[08:46] <anpok_> first I or someone else has to clean up the resize handling
[08:47] <duflu> Just wondering... if I introduce a new feature for swap_buffers_sync only initially will most users benefit?
[08:47] <duflu> The async case requires threads and mess. I'd rather separate it
[08:47] <duflu> Possibly an event loop instead
[08:54] <duflu> Hurray, EGL uses a different code path, unnecessarily?
[08:55] <alan_g> greyback: sorry, that seems to be a clang flag
[08:55] <greyback> ok
[09:14] <alan_g> greyback: pushed a version that works with g++
[09:15] <alan_g> I hope
[09:15] <greyback> ack
[09:29] <greyback> alan_g: I believe you have a NOT missing in your logic. You check if "-Wno-something" is set, and if it is, append -Wno-something.
[09:30] <alan_g> I think I check if  "-Wno-something" is supported by the compiler and, if it is, set it. I guess it doesn't work?
[09:30] <alan_g> Got a meeting, back soon
[09:31] <greyback> nope, sorry
[09:33] <greyback> http://pastebin.ubuntu.com/23552532/ - the clang cmd line option is added
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[10:28] <alan_g> /sigh check_cxx_compiler_flag() isn't as magic as I thought.
[10:34] <alan_g> greyback: I think I've got it
[10:37] <greyback> alan_g: well that fixes gcc!
[10:37] <greyback> zesty clang now found another error
[10:38] <greyback> http://pastebin.ubuntu.com/23552717/
[10:43]  * alan_g mutters about users
[10:43] <greyback> http://pastebin.ubuntu.com/23552731/ fixes that issue (and a class/struct complaint) for clang
[10:45] <alan_g> Feel free to propose that (you can drop "public" too)
[10:46] <greyback> ok
=== chihchun is now known as chihchun_afk
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
=== dandrader is now known as dandrader|afk
=== alan_g is now known as alan_g|bbiab
=== dandrader|afk is now known as dandrader
=== greyback is now known as greyback|afk
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== greyback|afk is now known as greyback