kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 5 September 2013 23:25, Dick Hollenbeck <dick@xxxxxxxxxxx> 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.