Hmm, this crashes in the fedora nightly build during pcbnew startup, I need to investigate why. https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147 snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')", WXPYTHON_VERSION ); PyRun_SimpleString( cmd ); Miguel Ángel Ajo On Tuesday, 17 de February de 2015 at 17:31, Brian Sidebotham wrote: > On 16 February 2015 at 17:44, Wayne Stambaugh <stambau...@gmail.com > (mailto:stambau...@gmail.com)> wrote: > > On 2/16/2015 11:44 AM, Brian Sidebotham wrote: > > > On 16 February 2015 at 15:42, Brian Sidebotham > > > <brian.sidebot...@gmail.com (mailto:brian.sidebot...@gmail.com)> wrote: > > > > On 16 February 2015 at 14:17, Wayne Stambaugh <stambau...@gmail.com > > > > (mailto:stambau...@gmail.com)> wrote: > > > > > Brian, > > > > > > > > > > How are you telling the kicad configuration where wxPython build is > > > > > located during you winbuilder configuration? Would Garth's solution > > > > > below solve your problem? The only issue I see with Garth's solution > > > > > is > > > > > that if you install wxPython somewhere other than where you defined > > > > > PYTHON_SITE_PACKAGE_PATH, you would be right back to where you > > > > > started. > > > > > In other words you could build kicad but when you launched the python > > > > > console, it would most likely crash because wxPython would not be > > > > > located at PYTHON_SITE_PACKAGE_PATH or worse a different version of > > > > > wxPython would be loaded. > > > > > > > > > > > > > > > > > Hi Wayne, > > > > > > > These days however packages like mingw-w64-python2 exist and so really > > > > we should be able to make use of that in KiCad-Winbuilder instead of > > > > the custom projects. I'll look into it. > > > > > > > > > > > > > I just checked > > > http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download > > > > > > Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a > > > show-stopper in my opinion because dwarf-2 is known to be broken with > > > regards to throwing exceptions across DLL boundaries. Since the Kiway > > > work there's no real option but to support exception throwing across > > > DLL boundaries otherwise exceptions cannot propagate correctly. > > > > > > > > > After all this time, this issue hasn't been addressed? This was an > > issue over 10 years ago. This makes me feel better about the bug fixing > > rate in KiCad. I'm not sure which code in KiCad would cause this error. > > Most of the exceptions that I can think of do not cross DLL boundaries. > > They only cross from the DLL to the main executable which does not > > fail. I just tested the pretty library parser which throws an IO_ERROR > > from _pcbnew.kiface to pcbnew.exe without any issues. I don't think > > wxWidgets raises any an most of Boost is the header libraries so that > > wouldn't be an issue either. Do Python exceptions cross over into C++ > > land? If so, that could be an error. > > > > > Hi Wayne, > > Thanks so much for doing a quick sanity check. I forget the check I > used to do. Perhaps it is no longer an issue these days and I'm worry > about a past issue. I'll try and re-base KiCad-Winbuilder off the > MSYS2 project MINGW repos for wxPython and python. > > With regards to Python throwing exceptions, it's written entirely in C > so there's no risk of it throwing exceptions. > > Best Regards, > > Brian. > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > (mailto:kicad-developers@lists.launchpad.net) > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ 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