[Slackbuilds-users] Dummy Package for wxWidgets?

B Watson yalhcru at gmail.com
Wed Feb 19 08:35:10 UTC 2020


On 2/18/20, Peter Dambier <peter at peter-dambier.de> wrote:
> Wellknown problem wxGTK3 and wxPython
>
> They can exist together but sometimes ...
>
> graphics/hugin complained about wxXwidget not found and wxX11 would not
> help.
>
> I installed wxGTK3 again. That helped. I guess next time I'll have to
> install wxPython again. No need to build again.
>
> Would it make sense to have a dummy package wxWidgets with only a README
> telling people to simply install wyPython or wxGTK3 again?

I dunno about a dummy package, we've successfully avoided those so far.

Problem you're having is, some builds use the wx-config command to get
the version, library path, etc. And wx-config will always give the
info for the most-recently-installed version. /usr/bin/wx-config is
actually a symlink to e.g. /usr/lib64/wx/config/gtk2-unicode-release-2.8
(for wxGTK3, the version number is different). And whichever package
was installed last, creates the symlink. It would have been *really*
nice if the wx devs had put the version number in the symlink filename
(e.g. wx-config2 vs. wx-config3), but they didn't.

There are a couple ways around this, if build maintainers are willing to
use them. Essentially what's required is to NOT trust /usr/bin/wx-config
to point to the version of wx that we want. Every build that uses
wx-config will have *some* way to override it (even if it's "sed or
patch the Makefile"). So every wx-using script should force the build
system to use the desired script in /usr/lib64/wx/config/.

Currently, the only possibilities with SBo's various wx* builds are:

/usr/lib$LIBDIRSUFFIX/wx/config/gtk2-unicode-release-2.8
/usr/lib$LIBDIRSUFFIX/wx/config/gtk2-unicode-3.0

So whichever version of wx is required by your script, use whatever
mechanism the authors provided to override the wx-config command, and
set it to the appropriate value from the list above. It'd be polite to
allow a user override via the environment, also.

For most builds, only one or the other version will work. So it's a
simple thing. From vbam.SlackBuild:

WXCONF=${WXCONF:-/usr/lib$LIBDIRSUFFIX/wx/config/gtk2-unicode-3.0}

vbam uses cmake, so later in the script
"-DwxWidgets_CONFIG_EXECUTABLE=$WXCONF" is passed as a cmake argument.

The user can set WXCONF in the environment to override the default,
if he's got some reason to want to do that.

What I do in sooperlooper is maybe overly complex:

WXVER=${WXVER:-2.8}
WXMAYBE="$( ls /usr/lib$LIBDIRSUFFIX/wx/config/*-$WXVER 2>/dev/null | head -1 )"
WXCONFIG=${WXCONFIG:-$WXMAYBE}
WXCONFIG=${WXCONFIG:-/usr/bin/wx-config}

...then later in the script, --with-wxconfig-path=$WXCONFIG is
passed to ./configure.

So what does this do? It uses 2.8 by default, but it allows the
user to override it in the environment, either setting WXVER to the
version number, or WXCONFIG to the full path to the wx-config script
(e.g. WXCONFIG="/usr/lib64/wx/config/gtk2-unicode-release-2.8").
The silliness about ls|head -1 is because (in theory anyway) you might
have multiple builds of 2.8 (unicode and non-unicode), though this should
never happen if you're sticking with SBo packages only. The last line
is a fallback: if it can't find any 2.8 script to use in the standard
location, it'll use wx-config from $PATH. Which will be the one from 3.0,
if you have only 3.0 installed.

All the above is because sooperlooper is capable of being built with
either version of wx* (2.8 or 3.0), but 2.8 is preferred (at least,
other distros were using it, when I last checked).

The *other* thing that would work: either version of wx-config will give
correct info for either version of wx, if the --version=<ver> argument
is passed to it. For whatever reason, upstream authors never seem to
actually *do* this in their (configure|cmake|Makefile|whatever). You
might try telling it to use "wx-config --version=2.8" (or 3.0, whichever
the build actually needs). This can be a PITA due to quoting rules making
it difficult to include spaces in arguments...


More information about the SlackBuilds-users mailing list