Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 491310 - x11-libs/wxGTK: migrate to x11-libs/gtk+:3
Summary: x11-libs/wxGTK: migrate to x11-libs/gtk+:3
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo wxWidgets project
URL: http://docs.wxwidgets.org/trunk/page_...
Whiteboard:
Keywords:
Depends on: 485184
Blocks:
  Show dependency tree
 
Reported: 2013-11-15 09:04 UTC by Nikoli
Modified: 2016-04-14 02:48 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch for ebuild (wxGTK-3.0.0.0.ebuild.patch,981 bytes, patch)
2014-01-27 06:26 UTC, Nikoli
Details | Diff
patch for eclass (wxwidgets.eclass.patch,771 bytes, patch)
2014-01-27 06:27 UTC, Nikoli
Details | Diff
changed files (wxgtk.diff,22.13 KB, patch)
2014-05-10 07:55 UTC, Nikoli
Details | Diff
patch for ebuild (wxGTK-3.0.1.1.ebuild.patch,856 bytes, patch)
2014-10-14 13:03 UTC, Nikoli
Details | Diff
patch for eclass (wxwidgets.eclass.patch,768 bytes, patch)
2014-10-14 13:04 UTC, Nikoli
Details | Diff
Patch against wxGTK-3.0.2.0-r1.ebuild (wxGTK-3.0.2.0-multibuild.patch,8.87 KB, patch)
2015-02-25 20:42 UTC, nE0sIghT
Details | Diff
Patch against wxGTK-3.0.2.0-r1.ebuild (wxGTK-3.0.2.0-multibuild.patch,9.11 KB, patch)
2015-02-25 20:47 UTC, nE0sIghT
Details | Diff
Patch against wxGTK-3.0.2.0-r1.ebuild (wxGTK-3.0.2.0-multibuild.patch,7.88 KB, patch)
2015-05-22 15:58 UTC, nE0sIghT
Details | Diff
Patch against wxGTK-3.0.2.0-r2.ebuild (wxGTK-3.0.2.0-multibuild.patch,2.86 KB, patch)
2015-08-06 18:11 UTC, nE0sIghT
Details | Diff
wxwidgets.eclass-gtk3.patch (wxwidgets.eclass-gtk3.patch,2.09 KB, patch)
2016-01-29 06:15 UTC, Ryan Hill (RETIRED)
Details | Diff
wxGTK-3.0.2.0-r300.ebuild (wxGTK-3.0.2.0-r300.ebuild,4.92 KB, text/plain)
2016-02-09 01:10 UTC, Ryan Hill (RETIRED)
Details
wxGTK-3.0.2.0-r300.ebuild (wxGTK-3.0.2.0-r300.ebuild,4.97 KB, text/plain)
2016-02-09 23:37 UTC, Ryan Hill (RETIRED)
Details
wxwidgets.eclass (wxwidgets.eclass,3.67 KB, text/plain)
2016-02-10 00:01 UTC, Ryan Hill (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikoli 2013-11-15 09:04:37 UTC
Upstream now supports gtk3, please migrate to it:
"Support for GTK+ 3 is available starting with wxWidgets 2.9.4, use configure option –with-gtk=3 to enable it."
Comment 1 Ryan Hill (RETIRED) gentoo-dev 2013-11-16 04:53:18 UTC
Does adding that option work for you?  Here it can't find gtk/gtk.h.
Comment 2 Nikoli 2013-11-16 14:19:23 UTC
Same here. Seems it does not add -I/usr/include/gtk-3.0 to CFLAGS.
Comment 3 Mart Raudsepp gentoo-dev 2013-12-10 08:48:16 UTC
this was fixed in 2.9.5 by https://github.com/wxWidgets/wxWidgets/commit/497b4e64ceeff10f40104d26139fa7f1ee347095
Comment 4 Nikoli 2013-12-10 09:22:07 UTC
So will you add 2.9.5 to portage? Seems adding 3.0.0 is delayed.
Comment 5 Mart Raudsepp gentoo-dev 2013-12-10 10:10:34 UTC
I'm currently hacking 2.9.5 to work for my own needs, but I don't feel confident on adding that myself, as dirtyepic has been taken care of these things for quite a while. Also, hopefully 3.0 is out soon, as there was some activity earlier today towards that. I'm pestering RobinD quite consistently, hopefully not too much though :D

Either way, wxpython doesn't support gtk3 as WXPORT yet. Hopefully this will change by 3.0, but not sure. Can monitor in https://github.com/wxWidgets/wxPython/blob/master/config.py#L906 I suppose.
Comment 6 Nikoli 2013-12-10 10:18:20 UTC
3.0 is out, see bug #491308 Or do you mean wxpython?
Comment 7 Mart Raudsepp gentoo-dev 2013-12-10 13:46:15 UTC
(In reply to Nikoli from comment #6)
> 3.0 is out, see bug #491308 Or do you mean wxpython?

Of course I mean wxpython, as we are blocked on not having wxpython 3.0.x tarballs, as seen by the wxGTK3 bug.
Comment 8 Ryan Hill (RETIRED) gentoo-dev 2013-12-12 01:49:58 UTC
Sorry about the delay, I was looking into ways to streamline parallel installs and get rid of some of this wrapper hackery now that portage has evolved some of the features we need.  I would really like to be able to install both gtk2 and gtk3 ports together.  I don't think we're quite there yet though :/

I'll do the bump and an eselect-wxwidgets release over the holidays, and the wxSQlite addition and the other items you've pinged me on.
Comment 9 Mart Raudsepp gentoo-dev 2013-12-29 08:17:07 UTC
(In reply to Ryan Hill from comment #8)
> I would really like to be able to
> install both gtk2 and gtk3 ports together.  I don't think we're quite there
> yet though :/

I'm not sure if this is even a good idea. Unless you mean separate revisions, possibly in separate slots as other gtk2 vs gtk3 using libraries.
See https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
Though wxWidgets in a sense is a bit special, in that its purpose really is to actually hide what the underlying toolkit is, effectively reaching this true cross-platformness that its point is. I'm not sure gtk2 vs gtk3 is any different than wxGTK vs wxOSX in that sense then.
Either way, you shouldn't install support for both gtk slots in the same slot - has to be different slots too then.
I would like it to eventually be only against gtk3 (wearing both my wx and my gnome hat), but there are two things to keep in mind there:

1) early wxpython3 might have a problem - not sure if Robin fixed the toolkit strings to accept gtk3 in time for 3.0.0.0; or maybe we need to adjust eselect-wxwidgets for it;
2) applications/libs using and linking to both wxGTK and gtk+ for doing advanced per-platform things wxWidgets isn't quite capable of yet - while linking to both gtk2 (from the app using gtk directly too) and gtk3 (from wxGTK) will lead to runtime crashes (or gtk refusing to start as a safeguard)

> I'll do the bump and an eselect-wxwidgets release over the holidays, and the
> wxSQlite addition and the other items you've pinged me on.

So 3.0.0.0 is possible now; I hope you'll take care of it, and I'll try to pitch in with any smaller bumps in the future, now that I'm actually porting my only active wx project to Linux.
Comment 10 Ryan Hill (RETIRED) gentoo-dev 2013-12-29 09:50:38 UTC
(In reply to Mart Raudsepp from comment #9)
> I'm not sure if this is even a good idea. Unless you mean separate
> revisions, possibly in separate slots as other gtk2 vs gtk3 using libraries.
> See https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
> Though wxWidgets in a sense is a bit special, in that its purpose really is
> to actually hide what the underlying toolkit is, effectively reaching this
> true cross-platformness that its point is. I'm not sure gtk2 vs gtk3 is any
> different than wxGTK vs wxOSX in that sense then.
> Either way, you shouldn't install support for both gtk slots in the same
> slot - has to be different slots too then.

Blech.  Well, the plan was simply to build twice and install libwx_gtk2u* and libwx_gtk3u*.  Again, completely untested - there were issues that prevented us doing this with debug/release builds previously but I don't remember what they were.  Ebuilds would be built against the gtk3 libs unless they opted out with need-wxwidgets().

If that's not kosher then no problem.  Less work for me! :p

> I would like it to eventually be only against gtk3 (wearing both my wx and
> my gnome hat), but there are two things to keep in mind there:
> 
> 1) early wxpython3 might have a problem - not sure if Robin fixed the
> toolkit strings to accept gtk3 in time for 3.0.0.0; or maybe we need to
> adjust eselect-wxwidgets for it;
> 2) applications/libs using and linking to both wxGTK and gtk+ for doing
> advanced per-platform things wxWidgets isn't quite capable of yet - while
> linking to both gtk2 (from the app using gtk directly too) and gtk3 (from
> wxGTK) will lead to runtime crashes (or gtk refusing to start as a safeguard)

Yeah, that's exactly the situation I was hoping to avoid.  I fully expect that we'll end up with two higher-profile packages requiring different gtk versions.  Aside from external linking, are we expecting any porting problems between wxGTK-gtk2/3 (modulo port bugs of course)?

> > I'll do the bump and an eselect-wxwidgets release over the holidays, and the
> > wxSQlite addition and the other items you've pinged me on.
> 
> So 3.0.0.0 is possible now; I hope you'll take care of it, and I'll try to
> pitch in with any smaller bumps in the future, now that I'm actually porting
> my only active wx project to Linux.

Cool, perfect timing.
Comment 11 Mart Raudsepp gentoo-dev 2013-12-29 10:14:01 UTC
(In reply to Ryan Hill from comment #10)
> Blech.  Well, the plan was simply to build twice and install libwx_gtk2u*
> and libwx_gtk3u*.

I think even I would mind that extra compile time, if somehow not able to choose. And a USE flag based approach is also not ideal, and against GNOME policies (which are not a requirement though, but a good guideline to mitigate migration issues and time moving everything that matters to gtk3).
Aside of that, I see it hard to track that way which wxGTK package consumers want gtk2u, which gtk3u, and which don't care. This is an issue in the future in getting rid of the gtk2u one completely when it's not really maintained anymore and we start a drive to get everything using only gtk3.

> Again, completely untested - there were issues that
> prevented us doing this with debug/release builds previously but I don't
> remember what they were.  Ebuilds would be built against the gtk3 libs
> unless they opted out with need-wxwidgets().
> 
> If that's not kosher then no problem.  Less work for me! :p

Well, you could somehow do separate SLOTs as mentioned. That's probably more work for you with all the file collision potentials, as headers and such probably don't naturally get installed in different places by upstream gtk2 vs gtk3.

Personally I wish something (wxpython3 really) in the tree FAST; be it just gtk2 for all I care :)
But I suppose it could mean extra work in the long-run if not going the final solution gtk 2vs3 immediately.

> Aside from external linking, are we expecting any porting
> problems between wxGTK-gtk2/3 (modulo port bugs of course)?

I really don't know how good the gtk3 port is; my upstream activity ceased in 2008ish and I haven't kept any track on things. Guess we'll have to wait and see.

> Cool, perfect timing.

1 month late for my project, but yeah, delayed for other unrelated reasons too :D
Comment 12 Ryan Hill (RETIRED) gentoo-dev 2013-12-30 09:18:03 UTC
I've left it at gtk2 for now and we'll revisit it later.
Comment 13 Nikoli 2014-01-27 06:26:12 UTC
Created attachment 368850 [details, diff]
patch for ebuild
Comment 14 Nikoli 2014-01-27 06:27:23 UTC
Created attachment 368852 [details, diff]
patch for eclass
Comment 15 Nikoli 2014-01-27 06:35:56 UTC
With these patches and x11-libs/gtk+-3.8.7 wxGTK-3.0.0.0 builds fine for me. Tried several USE flags combinations, all of them worked fine. 

media-video/aegisub-3.1.0, media-video/mkvtoolnix-6.7.0, media-gfx/tintii-2.8.2 build and work fine with gtk3, but dev-python/wxpython-3.0.0.0 fails to build, portage tree does not have any other packages with WX_GTK_VER="3.0"
Comment 16 Nikoli 2014-02-13 08:53:17 UTC
So when do you plan to add (optional?) support for gtk3? It is required for app-i18n/poedit version bump.
Comment 17 Ryan Hill (RETIRED) gentoo-dev 2014-02-14 04:59:55 UTC
Yes I know, I do read my bugmail.  We either need to build both versions in the existing ebuild, add a new SLOT for gtk3, or have a whole new wxGTK3 ebuild.  All of these options are ugly and require a ton of work.  It's going to take a while.
Comment 18 Nikoli 2014-02-14 05:11:04 UTC
Adding new SLOT or new package would require changing a lot other packages, why not just add USE gtk3 or gtk2 to current wxGTK-3.0.0.0.ebuild? It can be done fast and does not break any of tree ebuilds. May be we will never need ability to install both gtk2 and gtk3 versions of wx3 libs at same time.
Comment 19 Ryan Hill (RETIRED) gentoo-dev 2014-02-14 06:17:05 UTC
That's what I want to do and IMO is the only sane option, but it's against the Gnome team's policies as we discussed above.

I think I can address leio's concerns though: re. compile time, it would be the same amount of time if you had separate SLOTs/packages, ie. you're still building once for gtk2 and once for gtk3.  The only case where there would be increased compile time is if you just wanted gtk3, which is unlikely any time soon.

As far as keeping track of which packages need gtk2/gtk3, you can check the dependency (x11-libs/wxGTK[X,gtk3]).  There would also be a new configuration for need-wxwidgets (gtk3-unicode/gtk-base-unicode).  For the simple inherit case, we could add ${WX_GTK3_VER} to select gtk3 versions, or something like ${WX_TOOLKIT} to let people pick one explicitly.  In any case, ebuilds will have to opt-in to use gtk3 so we can easily tell which ones use which toolkit.
Comment 20 Nikoli 2014-04-23 08:02:15 UTC
Ping, is there any progress?
Comment 21 Ryan Hill (RETIRED) gentoo-dev 2014-05-10 06:32:08 UTC
No, I haven't had time to work on this.  I need to get gcc-4.9 out the door first.

If you want to help, can you check if there are any differences between the installed files of a gtk2 and gtk3 build?  I mean the headers, bakefile presets, etc.  That will help decide which approach would be better.
Comment 22 Nikoli 2014-05-10 07:55:11 UTC
Created attachment 376646 [details, diff]
changed files

> can you check if there are any differences between the installed files of a gtk2 and gtk3 build?  I mean the headers, bakefile presets, etc.

Installed to /usr/include/wx-3.0 headers are same (compared size and md5), but 3 files are only installed when building with gtk2:
/usr/include/wx-3.0/wx/aui/tabartgtk.h
/usr/include/wx-3.0/wx/generic/fontdlgg.h
/usr/include/wx-3.0/wx/gtk/hildon/notifmsg.h

/usr/lib64/libwx_gtk* are different, other libs are exactly same.

Installed to /usr/lib64/wx/ files are different.

Nothing in /usr/share/ is changed.
Comment 23 Ryan Hill (RETIRED) gentoo-dev 2014-05-10 08:16:37 UTC
Thanks.  Based on that then I think we'll go with gtk2 and gtk3 in the same ebuild.  Otherwise we'd have to do a lot of ugly things to prevent file collisions.
Comment 24 Nikoli 2014-10-14 13:03:24 UTC
Created attachment 386666 [details, diff]
patch for ebuild
Comment 25 Nikoli 2014-10-14 13:04:02 UTC
Created attachment 386668 [details, diff]
patch for eclass
Comment 26 Nikoli 2014-10-14 13:09:09 UTC
I tested how well packages from tree now work with x11-libs/wxGTK-3.0.1.1 compiled with x11-libs/gtk+-3.12.2, list of ebuilds i tested:
=dev-python/wxpython-3.0.1.1
=games-emulation/vbam-1.8.0.1228
=games-engines/odamex-0.7.0
=games-simulation/corsix-th-0.30
=media-gfx/hugin-2014.0.0-r1
=media-gfx/tintii-2.9.0
=media-video/aegisub-3.1.2
=media-video/mediainfo-0.7.70
=media-video/mkvtoolnix-7.2.0
=net-ftp/filezilla-3.9.0.5

Only wxpython fails to build, all other packages rebuild fine with wxgtk3+gtk3, none of them crashes when running. mediainfo-gui does not show info, did not find any other problems in other packages, but i did not test them much.
Comment 27 nE0sIghT 2015-02-25 20:42:00 UTC
Created attachment 397516 [details, diff]
Patch against wxGTK-3.0.2.0-r1.ebuild

Here is patch against wxGTK-3.0.2.0-r1.ebuild that introduces multibuild (gtk-2 + gtk-3) support as well as multilib support (bug #510708).

I made gtk-3 build required and gtk-2 build optional via gtk use flag because i do not know a better way for this package.

Be aware that in worst case (x86-gtk2, x86-gtk3, amd64-gtk2, amd64-gtk3) this ebuild need about 6 GiB in PORTAGE_TMPDIR
Comment 28 nE0sIghT 2015-02-25 20:47:25 UTC
Created attachment 397520 [details, diff]
Patch against wxGTK-3.0.2.0-r1.ebuild

Adjusted gtk+ dependencies
Comment 29 nE0sIghT 2015-05-22 15:58:55 UTC
Created attachment 403772 [details, diff]
Patch against wxGTK-3.0.2.0-r1.ebuild

Removed wrong ECONF_SOURCE
Changes: https://github.com/nE0sIghT/vortex-overlay/commit/b8b8587672f1706b1d0e06e99099a1def5661d1b
Comment 30 nE0sIghT 2015-08-06 18:11:26 UTC
Created attachment 408422 [details, diff]
Patch against wxGTK-3.0.2.0-r2.ebuild

Updated to match latest main tree changes
Comment 31 Ryan Hill (RETIRED) gentoo-dev 2015-08-07 00:56:50 UTC
That's half the battle, but we'll also need eclass changes to allow packages to specify which version they will build against, and changes to the eselect module for the update fallback code.

I had something hammered out last year but when I got looking at the multilib stuff I honestly just lost interest.  So thanks for doing the hard work. ;)  I'll see if I can rebase it onto your changes.
Comment 32 Priit Laes (IRC: plaes) 2016-01-27 19:36:49 UTC
(In reply to Ryan Hill from comment #31)
> That's half the battle, but we'll also need eclass changes to allow packages
> to specify which version they will build against, and changes to the eselect
> module for the update fallback code.
> 
> I had something hammered out last year but when I got looking at the
> multilib stuff I honestly just lost interest.  So thanks for doing the hard
> work. ;)  I'll see if I can rebase it onto your changes.

Could you flesh out a todo list, so people interested in getting this done could help?
Comment 33 Mart Raudsepp gentoo-dev 2016-01-28 14:02:49 UTC
Given time has passed, do we really need gtk2 version at all?
Is some package not working against gtk3? Or meant for the purpose of outside tree usage by developers making use of wxWidgets?
Comment 34 Priit Laes (IRC: plaes) 2016-01-28 15:01:08 UTC
(In reply to Mart Raudsepp from comment #33)
> Given time has passed, do we really need gtk2 version at all?
> Is some package not working against gtk3? Or meant for the purpose of
> outside tree usage by developers making use of wxWidgets?

Well, at least KiCAD's legacy mode for PCB-editor is broken: https://bugs.launchpad.net/kicad/+bug/1339539

Although the new GAL-mode seems to work OK so far and is alterative to legacy view, there might be people who are not happy with gtk3-only switch. ;)
Comment 35 nE0sIghT 2016-01-28 15:22:19 UTC
(In reply to Mart Raudsepp from comment #33)
> Given time has passed, do we really need gtk2 version at all?

games-emulation/pcsx2 must be explicitly built against gtk-3 if wxGTK was built against gtk-3: https://github.com/PCSX2/pcsx2/issues/397
Comment 36 Mart Raudsepp gentoo-dev 2016-01-28 16:40:40 UTC
Yes, that's what I mean with time has passed - applications that do extra things in #ifdef __WXGTK__ and whatnot to overcome the slight lowest common denominator of multiplatform toolkits limitations of wx API via platform specific extra code would hopefully be all ported to work together with gtk3 too by now or we can work with relevant upstream easily on that.
I know my own old project that only has a -9999 version in tree definitely hasn't, but can just remove that one from tree.

If anyone wants to check through all the wx using libs/apps, it would be nice to check for direct X11 usages as well, to prep for wayland, but I doubt wx itself is anywhere near it either, so not important at all I believe, but if someone's checking through the code anyways and it would be semi-automatic... (plus if something is doing so, it might be bound to how gdk-x11 is working and break with gdk3-x11 + that extra X code; though also unlikely imho)
Comment 37 Mart Raudsepp gentoo-dev 2016-01-28 16:41:56 UTC
... and then we would have in this specific case an ~arch pcsx2 that works with gtk3 introduced together with a wxGTK gtk3, and also later on stabilized together - to maintain things working at matching visibility levels
Comment 38 Ryan Hill (RETIRED) gentoo-dev 2016-01-28 18:59:11 UTC
wxpython is the big holdout for gtk2 that I know of.

I've written up a summary of what needs to be done that I'll post in a bit, but here are some open questions I have.

Do we want a new wxGTK3 package?  Do we want to make wxGTK install gtk3 and add a wxGTK2 legacy ebuild?  Or do we want one package installing both (with or without a gtk3 USE flag)?

What should the default toolkit be when inheriting the eclass?  ie. Do all packages using the defaults work with gtk3?  If gtk3, what do we do if gtk3 support isn't installed?  If gtk2, every ebuild wanting gtk3 will need to explicitly request it with need-wxwidgets.  Maybe that's the way we should be moving anyway, and drop the defaulting code?

If we add a gtk3 USE flag, and change the default toolkit to gtk3, all consumer ebuilds will need changes to their dependencies.  As well, all ebuilds using the defaults will need to be tested to ensure we don't break them.  If we add a legacy wxGTK2 package and change the current default to gtk3, we will only need to modify packages that don't work with gtk3, which is less work, but we still need to do the testing.  If we leave the default to gtk2 and require ebuilds to explicitly request gtk3 then we can leave the transition in the hands of the package maintainers, but that just means that it'll never get done. :)

I think the last option is probably the way to go.  At least, it would get the ability to use gtk3 into the tree now for those that want/need it.

In a perfect world the configuration used would be automatically determined by the atom that satisfied the wxGTK dependency in the ebuild.  If there's a way to access that information inside the ebuild environment I've yet to find it.
Comment 39 Ryan Hill (RETIRED) gentoo-dev 2016-01-29 06:15:48 UTC
Created attachment 424132 [details, diff]
wxwidgets.eclass-gtk3.patch

Here's a rough untested patch for the eclass in case people want to play around with it.
Comment 40 Mart Raudsepp gentoo-dev 2016-01-29 17:09:26 UTC
(In reply to Ryan Hill from comment #38)
> wxpython is the big holdout for gtk2 that I know of.

Priit says it works fine?

> Do we want a new wxGTK3 package?  Do we want to make wxGTK install gtk3 and
> add a wxGTK2 legacy ebuild?  Or do we want one package installing both (with
> or without a gtk3 USE flag)?

I would prefer a wxGTK:3.0 revbump (say -r300) that just switched over to using gtk3 instead of gtk2. Together with such a revbump, all wxGTK/wxpython stuff gets to work with gtk3 as well. And then 30-60 days later we stabilize all of them together. Those apps that do funky stuff with gtk directly and need to be recompiled or patched can grow a blocker to the new version, while the fixed version requires the new one, ensuring that everyone ends up with stuff working against gtk3.

Then the eclass needs to work based on what version the user has or something and we'd be done.

Is there any real reason to keep gtk2 support in parallel? I'd be coming knocking with gtk maintainer hat on soon to remove it when at all possible...
Comment 41 Ryan Hill (RETIRED) gentoo-dev 2016-01-30 00:36:01 UTC
(In reply to Mart Raudsepp from comment #40)
> (In reply to Ryan Hill from comment #38)
> > wxpython is the big holdout for gtk2 that I know of.
> 
> Priit says it works fine?

Fixed in 3.0.2.0.  Cool.

> > Do we want a new wxGTK3 package?  Do we want to make wxGTK install gtk3 and
> > add a wxGTK2 legacy ebuild?  Or do we want one package installing both (with
> > or without a gtk3 USE flag)?
> 
> I would prefer a wxGTK:3.0 revbump (say -r300) that just switched over to
> using gtk3 instead of gtk2. Together with such a revbump, all wxGTK/wxpython
> stuff gets to work with gtk3 as well. And then 30-60 days later we stabilize
> all of them together. Those apps that do funky stuff with gtk directly and
> need to be recompiled or patched can grow a blocker to the new version,
> while the fixed version requires the new one, ensuring that everyone ends up
> with stuff working against gtk3.

That's pretty much what I had in mind.

> Then the eclass needs to work based on what version the user has or
> something and we'd be done.

The "or something" is the whole problem.  We can't make it dependent on the version you have installed.  That would mean that upon stabilization of gtk3 wxGTK, every ebuild in stable would start using gtk3.  Every package already installed would switch toolkits if they were recompiled.  That's a major user-visible change with no version or rev bump, which is kind of the opposite of stable.  It's basically an automagic dependency.  Two users with the same version of a package installed with the same USE flags should not get two different results based on what happened to be installed at the time they were built.

If you accept that, the question becomes how do we get new ebuilds using gtk3 while still keeping stable stable.

I don't have a good solution, which is why this bug has been open as long as it has.  Everything I come up with ends up coming back to the same thing - ebuilds have to opt in to gtk3.  I don't like it - I agree they should get it by default - but I don't see another answer.

There's a few different ways to do this (different SLOT, new package, USE flag) and each has different (dis)advantages.  I went with the USE flag because it was easy and I could bash it together before bed, but I'm open to anything.


> Is there any real reason to keep gtk2 support in parallel? I'd be coming
> knocking with gtk maintainer hat on soon to remove it when at all possible...

I remember the GTK-1 removal.  I think you might need a helmet.
Comment 42 Mart Raudsepp gentoo-dev 2016-01-31 03:32:18 UTC
So I guess we'll have to define a WX_GTK_VER="3.0-gtk3", which doesn't have to coexist with WX_GTK_VER="3.0" (gtk2) support out of wxGTK package, as long as we limit the versions up in all wxGTK consumers; and check that in a dynamic language like python everything keeps on working seamlessly without having to rebuild things either way. Sadly that means still touching all consumer packages then..
Comment 43 Ryan Hill (RETIRED) gentoo-dev 2016-01-31 04:33:40 UTC
Heh, I was playing around with implementing this a few different ways today and just came here to say I think the best way is to add WX_GTK_VER="3.0-gtk3".  So I guess we're in agreement.

I'll put together a new ebuild and the eclass changes we'll need.
Comment 44 Ryan Hill (RETIRED) gentoo-dev 2016-02-09 01:10:35 UTC
Created attachment 425018 [details]
wxGTK-3.0.2.0-r300.ebuild

There's quite a few places where the release number is used behind the scenes.  I probably missed some.

Next up is some eclass changes.
Comment 45 Ryan Hill (RETIRED) gentoo-dev 2016-02-09 06:28:10 UTC
Comment on attachment 425018 [details]
wxGTK-3.0.2.0-r300.ebuild

Yep, this breaks everything using WX_CONFIG_CHECK.
Comment 46 Ryan Hill (RETIRED) gentoo-dev 2016-02-09 23:37:12 UTC
Created attachment 425094 [details]
wxGTK-3.0.2.0-r300.ebuild

This one keeps characters out of the output of wx-config --version which was upsetting some autoconf macros.
Comment 47 Ryan Hill (RETIRED) gentoo-dev 2016-02-10 00:01:19 UTC
Created attachment 425096 [details]
wxwidgets.eclass

Here's the eclass, very lightly tested.  It's pretty much rewritten so there's no point in a diff.

need-wxwidgets was necessary when we had multiple charsets/toolkits available to give ebuilds a way to pick the config they needed.  These days all the options can be determined just from the version of wxGTK required and the USE flags it was built with.  So I've renamed need-wxwidgets to setup-wxwidgets to better reflect that.  It takes no arguments (we've been ignoring arguments to need-wxwidgets for a while now).

I'm deprecating the global code that sets a config just by inheriting the eclass.  It requires $(get_libdir) which can't be used in global scope in EAPI 6.  I'll leave it in place for backwards compatibility for earlier EAPIs, but EAPI 6 ebuilds will have to call setup-wxwidgets somewhere.  I haven't added EAPI 6 support yet, but it will essentially be just shoving that global code into the EAPI case statement.  I need to see if use_if_iuse will still work or if we need to replace it with something else in 6.

For anyone wanting to test gtk3, just change WX_GTK_VER to 3.0-gtk3 in an ebuild and see what explodes.
Comment 48 David Seifert gentoo-dev 2016-03-15 17:54:18 UTC
Thanks Ryan,
a significant impediment still remains: get_libdir() in global scope. On IRC, Ian proposed the following (short-term) fix, in order to make wxwidgets EAPI=6 compatible:
https://bpaste.net/show/b9d01fecc68b
i.e., this wraps all the global code in a helper function, and calls that helper function in global scope in EAPI<6 and requires a separate call in pkg_setup() if overridden by the ebuild.
Comment 49 Ryan Hill (RETIRED) gentoo-dev 2016-03-15 18:54:54 UTC
Thanks, I have this fixed already in a local branch that is waiting for me to finish testing.  It's pretty much the same thing just without the phase function since I don't want this code to be available to EAPI 6 ebuilds at all.  I'll try to push it out this week.
Comment 50 Ryan Hill (RETIRED) gentoo-dev 2016-04-14 02:48:51 UTC
wxGTK-3.0.2.0-r300 is now available.

I tested about 2/3 of the tree and had about a dozen failures.  I only tested wxpython as far as to confirm there would be many file collisions and versioning problems and it would need to be slotted somehow also.

Most of the failures were apps not being GTK3 ready, rather than wxGTK3 specific.  Codeblocks links in both libs.  There were some problems with stuff not working at runtime but relatively few build failures.  I found cmake does some annoying stuff looking for wx-config versions that manages to bypass the wrapper script so we'll need to make some changes there.  I'll start a tracker for these issues in a bit.