Bugzilla Bug 209150

wxGTK ebuild renames /usr/share/bakefile/presets/wx.bkl to wx26.bkl or wx28.bkl
and similarly for other files in this directory. Unfortunately, this completely
breaks use of presets/wx.bkl with Bakefile.

To give you an idea of the impact, it's akin to renaming wx/window.h header to
wx/window26.h -- the latter breaks all wxWidgets applications, the former
breaks it "only" for people using Bakefile to create their makefiles for wx
apps. In other words, at best it makes this part of the ebuild useless, because
the files won't be found and at worst it will cause developers using Gentoo to
use wrong file names in their .bkl files.

Suggested fixes:

1) treat it the same way you treat wxwin.m4, or
2) always use the latest version, or
3) use eselect to pick the one that will be available, or
4) use non-standard directory for them -- that way, people can at least set
BAKEFILE_PATHS to point to it

Reproducible: Always

hmm.  i'm unfamiliar with Bakefile so i mirrored what freebsd's port does.  you
may want to hit them with a cluebat too.

for wxwin.m4, the changes between versions were so minimal that we could just
install the latest version.  the diff between the bkl files seems much more
substantial, and I'd hate to break older versions.  it seems like having the
eselect module handle this would be the best solution, since it's supposed to
cater more to the wxWidgets developer using Gentoo than the regular Gentoo user
using wxWidgets.

if symlinking the wx*${VER}.bkl files to wx*.bkl works i'll add that to the
module and drop the wx.bkl hunk(s) of the wxGTK collision patch.

what do you think?

(In reply to comment #1)
> if symlinking the wx*${VER}.bkl files to wx*.bkl works i'll add that to the
> module and drop the wx.bkl hunk(s) of the wxGTK collision patch.
> 
> what do you think?

Sounds good to me, thanks! 

Released in eselect-wxwidgets-0.8.  If you have any other problems with or
suggestions about our setup, please don't hesitate to tell us. ;)