On 5 September 2013 23:25, Dick Hollenbeck <d...@softplc.com> wrote: > On 09/05/2013 05:03 PM, Brian Sidebotham wrote: > > One of those moments! Ahhhhhhhhh! > > > > This problem is now "fixed". It happened to be that the wxWidgets DLLs > need to be in the > > environment's PATH list for python. Although .pyd's are loaded from > PYTHONPATH and the > > compiled-in paths, dependencies within the pyd are searched for on the > normal windows PATH > > variable (At least that's the behaviour I'm seeing). > > > > pcbnew loads some wxWidget dll's, but doesn't require the stc dll, so > this is never > > loaded. Hence, python has to search for the wxwidgets stc dll to load it > as it's not > > already been loaded, which fails. Adding kicad\bin to the environment > PATH solves the > > problem for me and the scripting console appears to work. > > > > There's still some confusion about this though. because everything works > well under plain > > python no matter what the environment PATH is set to - it never failed, > but then it really > > shouldn't and neither should KiCad because the standard DLL search path > starts with the > > current working directory. Now I'm wondering, does KiCad/pcbnew change > it's working > > directory for some reason? > > > > Anyway, the problem is solved for KiCad-Winbuilder. I can get a release > together now. > > > > I used some fprintf's in the end through python's dynload_win.c, but > there wasn't much > > more information to glean tbh - but at least I could reliably see the > load fail. > > > > Best Regards, > > > > Brian. > > > > > > > So I was precisely correct. :) As to why the other python works, .... > possibly registry > contents plays a role. (I have long thought that that os call can > alternatively use > registry contents. How else to all the other windows programs find their > quirky DLLs in > various places and you don't see those paths in the PATH environment > variable.) > > > Anyways, since we are putting zilch into the registry, the PATH was my > biggest concern. > Even though python a-mingw-us does not need registry contents, and as > policy we've chosen > not to use it. This policy does not necessarily extend to wxPython or > wxWidgets DLLs. > That's for you to decide. > > > Thanks for your HARD work. You are blazing a new trail, tough work, > doable only by a very > competent sort of guy! > >
Thank-you again Dick. It's good to see these things finally coming to fruition. I hope people are eager about the python scripting (Certainly seems like it's that way so far) and people will help by contributing scripts to do a multitude of new functionality. Thanks for all your pointers, they always point me in the right direction when I can't see the wood for the trees! Best Regards, Brian.
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
