wxPython 4.0 (Phoenix)

[neurodroid (Christoph Schmidt-Hieber)]

This is a request to get wxPython 4.0 (Phoenix) integrated into MacPorts. mojca worked on this a couple of years ago, but it was difficult to build Phoenix at the time. Currently the build toolchain works just fine without any particular acrobatics (as of r34521dc1 from ​https://github.com/wxWidgets/Phoenix):

git clone git@github.com:wxWidgets/Phoenix.git
cd Phoenix
git submodule update --init --recursive
CXXFLAGS='-I/opt/local/include' LDFLAGS='-L/opt/local/lib' python3.7 build.py dox etg --nodoc sip build

You'll need py37-sip to build Phoenix.

As wxPython 3.0 does not support Python 3, an upgrade to wxPython 4.0 is the only way to upgrade dependent ports to Python 3.

I cannot volunteer to maintain wxPython 4.0 for MacPorts, as I lack the required resources (mostly time & expertise).

[mojca (Mojca Miklavec)]

Last time I tried it did build out of the box, but not in the best way suitable for MacPorts. Whenever I tried to build it in MacPorts-friendly way, I got stuck.

We should not use the built-in libraries like libjpeg, and ideally I would like to use a standalone version of wxWidgets rather than using the one that's built-in.

I would need to check again. Are you able to figure out if it's somehow possible to use external wxWidgets & make sure that other dependencies also come from MacPorts rather than being built from provided sources?

[neurodroid (Christoph Schmidt-Hieber)]

Replying to mojca:

Last time I tried it did build out of the box, but not in the best way suitable for MacPorts. Whenever I tried to build it in MacPorts-friendly way, I got stuck.

We should not use the built-in libraries like libjpeg, and ideally I would like to use a standalone version of wxWidgets rather than using the one that's built-in.

I would need to check again. Are you able to figure out if it's somehow possible to use external wxWidgets & make sure that other dependencies also come from MacPorts rather than being built from provided sources?

wget https://files.pythonhosted.org/packages/9a/a1/9c081e04798eb134b63def3db121a6e4436e1d84e76692503deef8e75423/wxPython-4.0.6.tar.gz
tar -xzf wxPython-4.0.6.tar.gz
cd wxPython-4.0.6
# replace wscript with the latest version from github - could be included in a patch
wget https://raw.githubusercontent.com/wxWidgets/Phoenix/master/wscript
# wx-config is not in the PATH by default if installed via MacPorts
export PATH=${PATH}:/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/bin/
python3.7 build.py --use_syswx build_py
python3.7 demo/demo.py

[neurodroid (Christoph Schmidt-Hieber)]

To summarize, the two changes that are required so that you can build wxPython using only libraries provided by MacPorts are:

1. Patch wscript using the latest version from github

2. Make sure wx-config (from MacPorts' wxWidgets) can be found in your PATH

I only tested building against MacPorts' wxWidgets 3.0, as wxPython 4.0.6 appears to target wxWidgets 3.0.

[Veence (Vincent)]

Portfile for wx-python-4.0 (4.0.7 post2)

[Veence (Vincent)]

Patchfile to go with previously posted Portfile

[Veence (Vincent)]

Can someone else than me download and try the Portfile and patch file I just posted?

[ra1nb0w]

I did this last November but not merged; see ​https://github.com/ra1nb0w/macports-ports/tree/wxpython

Can you check if can be useful?

[Veence (Vincent)]

I committed my own Portfile to the main tree this afternoon. Please try and report any problem.

[mojca (Mojca Miklavec)]

First of all: thank you for looking into this, but next time please be more careful when doing such commits. The commit message doesn't follow our guidelines, the port name is somewhat misspelled, your commit message should not say "Please test" (if that was the intent, open a pull request first), you should reference the Trac ticket in commit message which will automatically create the link, or if you fail to do so, at least reference the commit itself manually in the Trac. (One thing I don't quite understand is why GitHub keeps referencing some weird pulls from another fork if you look at the individual commits.)

I left some notes next to the commit message.

[neurodroid (Christoph Schmidt-Hieber)]

This does currently not build on MacOS Catalina because wxPython 4.0.7post2 apparently ships with a version of wxWidgets < 3.1.3, which has a known issue with the WebKit headers:

​https://github.com/bincrafters/community/issues/1042

This issue has been fixed in wxWidgets 3.1.3.

Backporting the patch from wxWidgets 3.1.3 to the version of wxWidgets that is included with wxPython 4.0.7post2 fixes the problem on MacOS Catalina, i.e remove the HIWebView.h header test from configure, and add this conditional to webkit.mm:

#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_15
#include <WebKit/HIWebView.h>
#include <WebKit/CarbonUtils.h>
#endif

Having played around quite a bit with various versions of wxWidgets and wxPython, I agree with the strategy to use the version of wxWidgets that ships with wxPython, rather than the standard version of wxWidgets included in MacPorts.

The reason is that most of the time, wxPython will only support the version of wxWidgets with which it ships. Sometimes you can be lucky and there's a bit of tolerance but it's rare.

By the same token, I would advise against factoring out the version of wxWidgets that ships with wxPython as a separate port, as was done with previous versions of MacPorts wxPython (in the Python2x days).

First, this strategy avoids confusion between different versions of wxWidgets from the user's point of view.

Second, there's no reason why you would want to use the version of wxWidgets that ships with wxPython for any port other than wxPython.

Reported upstream: ​https://github.com/wxWidgets/Phoenix/issues/1506

[neurodroid (Christoph Schmidt-Hieber)]

As of py-wxpython-4.0 @4.1.1_7, these issues appear to be fixed.