kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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!


Dick