Please upgrade wxWidgets to 2.9.0, released 2009-09-11 Reproducible: Always
there were major structural changes in 2.9.0 and more after. i'm waiting on 2.9.1 before i start working it into the tree.
there are apps out there that require wxGTK 2.9 - hoxchess in my case. any chance you could change your mind? who knows how long 2.9.1 may take to come.
2.9.1 should be released in January, but I don't know how much fiddling I'll need to do with our setup to get it working. Previous versions did annoying things like installing libraries with different file names based on the USE flags used and we had to do a lot of hacky workarounds to make sure packages could find the right libraries when multiple versions were installed. 2.9.0 solves half the problem by getting rid of the separate ansi and unicode libs and 2.9.1 finishes the job by consolidating the release and debug libs. So I'm afraid that adding 2.9.0 now would require a reasonable amount of work which would then have to be done again for 2.9.1. I do plan on working on this as soon as 2.9.1 is released so hopefully you won't need to wait too long. If you know of any other packages that need 2.9 please let me know so I have something to test with.
For testing my hoxchess ebuild is up here ("sping" overlay): http://git.goodpoint.de/?p=overlay-sping.git;a=tree;f=games-board/hoxchess
I put a 2.9 live svn ebuild and updated eclass/eselect in my overlay. I haven't tested it much but it seems to be working. Any ebuild using wxGTK needs to be using wxwidgets.eclass to set it up. It's pretty easy: [...] WX_GTK_VER=2.9 inherit wxwidgets DEPEND=x11-libs/wxGTK:2.9[X] [...]
http://pastebin.com/TSi8wjU1 Any ideas?
I'm making progress on my ebuild, but am stuck at this: [code]# wx-config --libs --static Warning: No config found to match: /usr/lib/wx/config/gtk2-unicode-2.9 --libs --static in /usr/lib64/wx/config If you require this configuration, please install the desired library build. If this is part of an automated configuration test and no other errors occur, you may safely ignore it. You may use wx-config --list to see all configs available in the default prefix.[/code] Emerge output: http://pastebin.com/WYphGgEk
try the 2.9.1 ebuild in my overlay
We install the shared libs, not static. You'll have to figure out why it's trying to link against the static libs.
Okay the ebuild in my overlay is ready to go. I'd like some input on a couple things though. 1) the SLOT and thus WX_GTK_VER is currently 2.9. Do we want to make it 3.0? Because this is a development branch leading to stable 3.0, it might make sense to use 3.0 right from the beginning to prevent getting a number of ebuilds that need to be ported over when 3.0 eventually gets released (sometime after the 2nd apocalypse if I'm not mistaken). disadvantages: - Many spots in our code (ebuild, eclass, and eselect and wrappers) use SLOT or WX_GTK_VER as a shortcut to the versioned names of files (eg. wx-config), libraries, etc. They would have to be rewritten to deal with the mismatch. I've browsed it a bit and it looks like a fair amount of work. - The API is guaranteed to break during development. Maybe we actually do want a clean distinction which ebuilds work with 2.9 and with 3.0? - Developer confusion. "Why do I have to set WX_GTK_VER=3.0 to use wxGTK-2.9.1?!" advantages: - Less work migrating ebuilds later. Don't have a separate 2.9 SLOT to maintain (although maintenance after 3.0 is out and ebuilds are ported is reduced to putting it in a burlap sack and dumping it in the river). I'm for leaving it at 2.9. Porting doesn't scare me and I already have the sack. 2) The 2.9 series will never be stablized. I'm not for putting volatile APIs in places where we can't get rid of them later. If 3.0 takes 10 years to come out, 2.9 is relatively sane, and people really want to kill me I may revisit this policy at a later date. 3) We really need to move some of versioning code upstream, which I'm going to start working on. I may have broken wxstd.mo handling in this release but I don't know because I have no idea how to test it. These files (and others) really need to be versioned if upstream wants to continue to claim that multiple versions can be installed side-by-side. 4) No idea when new wxpython versions are coming out so I reverted back to using the wxWidgets distfiles.
Fixed.
