[Slackbuilds-users] wx(GTK|Python)-2.8 vs. wxGTK-3.0
yalhcru at gmail.com
Tue Sep 9 20:20:53 UTC 2014
[Apologies for the wall o' text here, I got kinda carried away...]
Ran into trouble building stuff that uses wxWidgets. The 2.x and 3.x branches
from the wxGTK3 README: "wxGTK3 can be installed alongside with wxGTK."
This is true, except for one detail: the symlink at /usr/bin/wx-config
gets overwritten when wxGTK3 is installed. Afterwards, trying to build
anything that depends on wxGTK (or wxPython) 2.x will fail. Attempting
the naÃve solution (removepkg wxGTK3) doesn't help, as it leaves the
symlink in place (and dangling).
The same problem happens the other way around of course, if wxGTK3 is
installed first, then wx(GTK|Python). Either way, you end up with failed
builds even though all the REQUIRES are installed.
Proposed solutions... I can think of a few, but someone else might think
of something better.
1. Have wxGTK3 use /usr/bin/wx-config3 or such, and pass
to ./configure (or the equivalent for cmake, scons, etc). Only a few builds
use wxGTK3 so far:
The builds using 2.x wouldn't have to be changed.
2. Pass --with-wx-config=/usr/lib$LIBDIRSUFFIX/wx/config/gtk2-unicode-release-2.8
to ./configure (or the equivalent for cmake, scons, etc), for stuff using 2.8,
and "gtk3-unicode-3.0" for stuff using 3.0. Fragile, will break when 3.1
replaces 3.0 eventually, or if a minor version update changes the filename
(maybe to gtk3-unicode-release-3.0, who knows?)
3. Have the wx packages create per-version directories
(e.g. /usr/lib$LIBDIRSUFFIX/wx-$VERSION) containing the wx-config symlink,
and every SlackBuild that uses wx can have:
Advantage is that the configure/cmake/etc commands don't have to be
modified, the block of code can just be inserted near the top of the
script for easy automation (with the 2.8 replaced with 3.0 where needed).
4. This bit of code:
WXMAYBE="$( ls /usr/lib$LIBDIRSUFFIX/wx/config/*-$WXVER 2>/dev/null | head -1 )"
...plus modifying the configure/cmake/etc options to use $WXCONFIG.
Requires more manual work than option 3, but it means the wxGTK3 and
wx(Python|GTK) builds themselves won't have to change.
5. No code changes at all, but add a paragraph to every wx-using package's
README that explains how to manually adjust the /usr/bin/wx-config
symlink if needed. I don't really like this option at all, but it's
the easiest to implement.
Option 1 is what I'd vote for. It requires fewer scripts to change than
options 2/3/4, and it's easier on the end user than option 5.
More information about the SlackBuilds-users