You can just strip *.so here, unless you want to know if and when the .so file list changes (minimal benefit)

But .. this whole block is commented out anyway. Why?

Document/comment patches in the patch headers with upstream or other references like issue, PR, mailing list, commit URL's and a short description, to help our future selves

Document/comment patches in the patch headers with upstream or other references like issue, PR, mailing list, commit URL's and a short description, to help our future selves

Document/comment patches in the patch headers with upstream or other references like issue, PR, mailing list, commit URL's and a short description, to help our future selves

Document/comment patches in the patch headers with upstream or other references like issue, PR, mailing list, commit URL's and a short description, to help our future selves

Document/comment patches in the patch headers with upstream or other references like issue, PR, mailing list, commit URL's and a short description, to help our future selves

Document/comment patches in the patch headers with upstream or other references like issue, PR, mailing list, commit URL's and a short description, to help our future selves

Document/comment patches in the patch headers with upstream or other references like issue, PR, mailing list, commit URL's and a short description, to help our future selves

Document/comment patches in the patch headers with upstream or other references like issue, PR, mailing list, commit URL's and a short description, to help our future selves

I uploaded my test sorry :)

Yes It's commented because... strip crash :/
I forgot to mention it at the first patch

If all the files are in /wx/, can you try *.so (without the loop), or using a ${FIND} ${STAGEDIR}${PYTHON_SITELIBDIR}/wx -name *.so -exec ${STRIP_CMD} ...

It would be nice to get to the bottom of the crash.

If all of the above still crash (let us know), please add a comment to the top of the commented block about why its commented, so that our future selves can isolate and hopefully fix it.

Is this correct?

Yes, wxPython40 requires wx-widgets 3.0 AFAIK no one uses 3.1 yet.

I see your comment in the revision summary "but I think that we need to modify also Mk/bsd.wx.mk."

Yes, as I had asked on IRC who was taking care of that, because, I don't really understand why there are two ports (wxPythonX and wxPythonX-common) per version.

This new port, it's the only one allowing to offer wxwidgets in python3 (and requested by the new version of databases/grass7 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241892)

For the wx ports framework, I didn't modify it because I don't know how much I have to modify it to include this new port.

In my example on databases/grass7, I don't use the variable

USE_WX=3.0
WX_COMPS=wx:build python:run

but

RUN_DEPENDS=	${PYTHON_PKGNAMEPREFIX}wxPython40>=0:x11-toolkits/py-wxPython40@${PY_FLAVOR}

I think that wxPython40 sould be callable within Mk/bsd.wx.mk, but how?

Should we replace py- wxPython30 by py-wxPython40 for wxgtk30 like this

_WX_PORT_python_3.0=	x11-toolkits/py-wxPython40
_WX_FILE_python_3.0=	${PYTHON_SITELIBDIR}/wx-3.0-gtk3/wx/__init__.py

Or, is it necessary to add something else to choose the version of wxPython (3 or 4) for wxWidgets (3.0). Knowing, that only wxPython40 is available for python3.

Maybe we need to integrate this port first and then run an exp-run by depreciating wxPython30 by wxPython40 and see the result?

AFAIK, no. I tried with PYDISTUTILS_BUILDARGS= WX_CONFIG=${WX_CONFIG} but there is no effect on the variable.
All linux distributions make this substitution. I'm going to open a ticket upstream.

It's possible to avoid these patch using a manual do-build:

do-build:
    ${PYTHON_CMD} ${WRKSRC}/build.py build --use_syswx --release

But it doesn't compile anymore (IIRC only with llvm...), because of an include problem:

...
In file included from ../../../../sip/cpp/sip_glcanvaswxGLContext.cpp:10:
In file included from ../../../../sip/cpp/sipAPI_glcanvas.h:524:
In file included from /usr/local/include/wx-3.0/wx/glcanvas.h:195:
In file included from /usr/local/include/wx-3.0/wx/gtk/glcanvas.h:14:
/usr/local/include/wx-3.0/wx/unix/glx11.h:13:10: fatal error: 'GL/glx.h' file not found
#include <GL/glx.h>
         ^~~~~~~~~~
1 error generated.

Waf: Leaving directory `/wrkdirs/usr/ports/x11-toolkits/py-wxPython40/work-py37/wxPython-4.0.7/build/waf/3.7/gtk3'
Build failed
 -> task in '_glcanvas' failed with exit status 1 (run with -v to display more information)
 -> task in '_glcanvas' failed with exit status 1 (run with -v to display more information)
 -> task in '_glcanvas' failed with exit status 1 (run with -v to display more information)
Will build using: "/usr/local/bin/python3.7"
...

I tried to build ports where wxPython30 was required with wxPython40 and all built successfully

(except emulators/playonbsd stage-qa for shebang errors and sysutils/hachoir-wx unfetchable)

erg no sorry for the false positive alert... need a second try with wxPython40 instead of wxPython30

koobs@ FYI, I opened an issue upstream

koobs, I also tried the commands follow up our discussion on IRC without success.