these are the new wxlib and wxwidgets eclasses. they allow us to easily build and use different wxGTK versions and types depending on our needs. some of the bigger changes: - install any combination of ansi, unicode, debug and release versions side by side - automatic USE flag checking - better error reporting - they actually work wxlib.eclass can go into the tree right away as nothing is using it right now. wxwidgets.eclass needs wxGTK-2.4 to go away first. with the new wxwidgets.eclass, there is no /usr/bin/wx-config. instead, each "type" installs it own config script with the naming convention /usr/bin/wx{base,gtk2}[u][d]-${WX_GTK_VER}-config (where u is unicode and d is debug). this is the biggest hurdle to overcome as most packages default to looking for a script called wx-config. most packages however can take an alternate name via a configure option or env variable, and we export a few env variables ourselves for ebuilds to use. the upshot of all this is that packages that use wxGTK MUST use wxwidgets.eclass to be able to find the configure script they need to use. down the road, the plan is to implement an eselect utility that will create a wx-config symlink to whatever flavor of wxGTK the user wants. this will allow people developing with wxGTK to quickly switch between debug and release versions. this is another reason that ebuilds can't be allowed to use it - at any given time it could point to anything (or nothing). these eclasses are incomplete. consider them a preview. while i have been working to get everything in the tree working with them, there's still some things that are broken, so use them at your own risk.
Created attachment 119489 [details] wxlib.eclass
Created attachment 119490 [details] wxwidgets.eclass
i should mention the new wxwidgets.eclass won't work with the wxGTK in portage. i will be posting new wxGTK ebuilds soon, as soon as i polish them up.
(In reply to comment #0) > wxlib.eclass can go into the tree right away as nothing is using it right now. Technically it is used to uninstall (part of the upgrade process as well) older versions of wxGTK that someone might still be using on a machine that is not fully updated often. > with the new wxwidgets.eclass, there is no /usr/bin/wx-config. instead, each > "type" installs it own config script with the naming convention > /usr/bin/wx{base,gtk2}[u][d]-${WX_GTK_VER}-config (where u is unicode and d is > debug). > > this is the biggest hurdle to overcome as most packages default to looking for > a script called wx-config. I wonder if we could maybe make usage of wx-config, that will be coming from the eselect module, to issue a QA warning if getting used during a portage driven usage. > these eclasses are incomplete. consider them a preview. while i have been > working to get everything in the tree working with them, there's still some > things that are broken, so use them at your own risk. I won't be able to review before next weeks second half for sure :(
Created attachment 122368 [details] wxGTK-2.6.3.3-r1.ebuild
Created attachment 122369 [details, diff] wxGTK-2.6.3.3-dialog_focus.patch
Created attachment 122371 [details, diff] wxGTK-2.6.3.3-slider_linesize.patch
Created attachment 122373 [details, diff] wxGTK-2.6.3.3-wxrc_build_fix.patch
Created attachment 122374 [details, diff] wxGTK-2.6.3.3-wxrc_link_fix.patch
Created attachment 122376 [details, diff] wxGTK-2.6.3-unicode-odbc.patch
Created attachment 122378 [details, diff] wxGTK-2.6.3-versionated.patch
wxlib.eclass changes have been merged into the ebuild and the debug options have been changed like we talked about. 99% of the tree is working with the new system but i'm planning on doing another run to make sure nothing was overlooked. only the versionated and unicode-odbc patches are new. i just posted the others so everything is in one place. ;)
"with the new wxwidgets.eclass, there is no /usr/bin/wx-config" I wonder how non Portage driven compiles are expected to work with that change... Will I have to modify configure scripts to workaround the different name?
(In reply to comment #13) > "with the new wxwidgets.eclass, there is no /usr/bin/wx-config" > I wonder how non Portage driven compiles are expected to work with that > change... An eselect module would be handling that symlink. > Will I have to modify configure scripts to workaround the different > name? No. Additionally you can also use what the eclass uses - call configure with an appropriate --with-wx-config value, or by setting some env vars (I think WX_CONFIG_NAME and co). But the eselect module would be used for making your choice for the _default_ wx to use in non-portage compilations.
(In reply to comment #12) > 99% of the tree is working with the new system but i'm planning on doing > another run to make sure nothing was overlooked. So, any news on this ?
Created attachment 130971 [details] wxwidgets.eclass this is what i'm playing with nowadays
in portage.
I am developping an app using wxWidgets and I need release and debug builds to coexist on my system. Although the original description of this bugs states that the wxGTK ebuild will 'install any combination of ansi, unicode, debug and release versions side by side' I am still enable to do it. I checked wxGTK-2.8.7.1-r1.ebuild in the tree and it does not seem to inherit wxlib.eclass nor implement any coexistence of builds. Can you please clarify the capabilities of the wxGTK ebuild? Thanks
concurrent installs of release and debug libraries was a planned feature but unfortunately proved to be very difficult to implement and maintain. i might revisit the issue in the future, but i'm pretty swamped with work right now.
