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. ;)
