Danny Milosavljevic writes: > Or maybe the attached patch captures the goal of wxwidgets better (which they IMO don't succeed at). > > I added gtk, opengl etc as native inputs instead of regular inputs because from the point of view of Python they are not direct inputs. > > wxPython only requires gtk while building the extension because wxwidgets does #include in their exported API (why...) - but after it's done it will not require it directly anymore and actually just require wxwidgets. > > Of course, the gtk version of wxwidgets will still require gtk by itself. > > That said, I still think it would be nicer if wxwidgets propagated gtk - since when you use wxwidgets, you also need to have gtk as well if wxwidgets was compiled for gtk - and the one deciding what wxwidgets is compiled for is the wxwidgets package. So it should go there... > > What do you think? Hello, I worked on your wxpython patch, and got wxpython to build, with kicad on top of it. Quite a lot of problems exist in the packages as of now. Regarding kicad, the built binary has the following issues: -In eeschema, the screen does not get redrawn automatically, leaving mouse traces. I found somewhere some suggestions, that building wxwidgets3.0 with gtk2 solves the issue, but I tried that and it does not. -When pcbnew is fired up, there is a "pcbnewInitPythonScripting() failed." message. Trying again, it opens normally (and effectively shows drawn pcb layouts), but with ui resizing issues. The ui resizing issues exist everywhere. -I have not added the kicad-libraries(components and footprints) in the package yet. On the build side of things, first of all, the update to boost 1.61.0 breaks the build of kicad, with a header missing error. I have reverted the latest changes in boost (to 1.60.1), in the patch, for development purposes. The wxpython package tries to install the wxPython headers in gnu/store/...-wxwidgets-3.0.2/include by default. I force set WXPREFIX in config.py to get around that. In turn, in the kicad package, the include path has to be set with a cmake flag, to find the wxPython headers. I am sure there is a better way to handle this, but this is how I got it to build for now. The phase that replaces 'install in wxpython, can be obviously ommitted, if your patch to honor configure-flags in python build phase is accepted. I think you are correct, in that wxwidgets should propagate gtk. I am waiting for some feedback on the patch. Greetings -- Theodoros Foradis