Building wxPython 4.1.0 [nixpkgs]

wxPython Dev
#1

Hi, i’m having some trouble building the latest release with Nix.

I have copied the 4.0 package
and added the PYTHONPATH fix from github PR #1584.

This results in the error pasted here,
the package definition that produced the error is also linked there.
Unfortunately i’m not particularly familiar with this kind of stuff.
My interest is due to a kicad issue that came up when i switched it to wxWidgets 3.1.

I believe i got the same error when i let wxPython build its own wxWidgets.

I haven’t found any documentation mentioning a change to the build process or a distro carrying 4.1.0 to compare against, if you know of such, i’d appreciate a pointer.

Thanks, Evils.

Compile fails in OpenSUSE Tumbleweed wxPython-4.2.0
#2

I suspect this is probably because you are building against a system copy of wxWidgets that is older than the wxPython release. wxPython 4.1.x is built against wxWidgets 3.1.x, which is not API/ABI stable, there are constantly changes being made do it. It appears that wxDelegateRendererNative::DrawCheckMark is relatively new: https://github.com/wxWidgets/wxWidgets/commit/2874dab7f004259d1d2aa9b79e68fc92543619f8#diff-30175ba7309d9bc957928d9b24413f34. It also seems that nixOS is still using wxWidgets 3.1.2 for its wx 3.1 release. This is probably the cause of the error.

I would caution you on trying to use a system copy of wxWidgets, especially with wxPython 4.1.x, since wxWidgets 3.1 can change at any time and wxPython doesn’t track a released version of wxWidgets. It just tracks a git reference.

#3

i’ve tried building wxPython 4.1.0 with wxWidgets 3.1.3 (i’ve got a PR open to bump nixpkgs to that)
and i think i have had it build its own wxWidgets
at least, i recall changing the build command to python3 build.py build fails in the same way

#4

apparently letting it build its own wxWidgets yields a different error, significantly later

#5

In your build where you let it build its own wxWidgets, it is failing because wxWidgets didn’t build with the OpenGL libraries:

checking for GL/gl.h... yes
checking for GL/glu.h... no
configure: WARNING: OpenGL libraries not available, disabling support for OpenGL

wxPython is supposed to handle cases where some of the wxWidgets components are missing (e.g., WebView) but in this case there is a bug. You can work around it by installing the OpenGL development packages. I don’t know what the package would be for nixos, but you need the package that contains GL/glu.h.

#6

Ok, with adding libGLU, wxPython 4.1.0 builds, but then kicad fails to find libwx_gtk3u_core-3.1.so.4 that’s in the wxWidgets built by wxPython.
Either because it’s being passed the “system” wxWidgets or because the wxPython package is a python package and doesn’t expose that file to dependents.

Am i right in thinking wxPython 4.1.0 ships an untagged version of wxWidgets?

There is a strong preference in nixpkgs to separate build products as much as possible.
If it is at all possible to use wxWidgets 3.1.3 in building wxPython 4.1.0 that would be the preferred way to solve this.
Other options would be to add relevant patches required by wxPython to our wxWidgets
or to build a separate wxPython_410.wxWidgets based on our wxWidgets, which has some quirks.

Thanks again, Evils.

#7

Yes, wxPython just tracks the master branch of wxWidgets. It doesn’t bundle a tagged release.

You could try getting the wxWidgets nixpkg updated to 3.1.3 and then try building wxPython 4.1.0 again…it might build with 3.1.3.

#8

i did try with wxWidgets 3.1.3, it didn’t build

889 commits between wxWidgets 3.1.3 and the pinned commit in wxPython 4.1.0 :cry:

i’m giving up for now…

Thanks for your clarifications.
Evils.

#9

Yeah, I would have preferred a tagged release too, but I’m not the one in charge. :frowning:

I’m a distribution packager too, so I feel your pain. :slight_smile: