Bugzilla Bug 178824

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 an attachment (id=119489) [details]
wxlib.eclass

Created an attachment (id=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 an attachment (id=122368) [details]
wxGTK-2.6.3.3-r1.ebuild

Created an attachment (id=122369) [details]
wxGTK-2.6.3.3-dialog_focus.patch

Created an attachment (id=122371) [details]
wxGTK-2.6.3.3-slider_linesize.patch

Created an attachment (id=122373) [details]
wxGTK-2.6.3.3-wxrc_build_fix.patch

Created an attachment (id=122374) [details]
wxGTK-2.6.3.3-wxrc_link_fix.patch

Created an attachment (id=122376) [details]
wxGTK-2.6.3-unicode-odbc.patch

Created an attachment (id=122378) [details]
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 an attachment (id=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.