← Back to team overview

kicad-developers team mailing list archive

Re: Python Scripting on Windows with KiCad-Winbuilder

 

This is a minor aside.  What's all involved in including a custom cmake
module in a project?  I fixed FindPythonLibs and another Python module for
cmake a few months ago, because right now those two stock modules don't
work on Fedora or Ubuntu--which means building Kicad on those platforms is
trickier than you'd expect.

They said my patches look fine, and they'd be glad to accept them--as soon
as they get a python maintainer for all of Cmake.

Adam Wolf
Wayne and Layne, LLC


On Sun, Aug 4, 2013 at 6:21 PM, Brian Sidebotham <brian.sidebotham@xxxxxxxxx
> wrote:

> On 4 August 2013 23:45, Brian Sidebotham <brian.sidebotham@xxxxxxxxx>wrote:
>
>> On 4 August 2013 22:42, Brian Sidebotham <brian.sidebotham@xxxxxxxxx>wrote:
>>
>>> On 4 August 2013 22:19, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>>>
>>>>
>>>> Any platform detection tests can cause grief, since we do not claim to
>>>> be Windows in the
>>>> python runtime.  We claim to be "gcc compiled" with some other
>>>> attribute that talks about
>>>> OS (cannot remember).  If you were to do a diff across the entire
>>>> bracket of a-ming-us
>>>> revisions,
>>>>
>>>> bzr diff -r 1..latest  <regression tests>
>>>>
>>>> limited to the regression test directories,
>>>> you will find one of the patches I applied to test for our platform
>>>> specifically.  It will
>>>> be the one with "gcc" in it.  We cannot report "Windows" as our
>>>> platform because mingw and
>>>> MSVC actually do a couple weird regression tests differently.
>>>>
>>>> If PyCrust is assuming a limited set of platforms, it may be coming up
>>>> short and running
>>>> into an unsupported platform code path.
>>>>
>>>>
>>>> Dick
>>>>
>>>
>>> Thanks for the great information Dick. I've just done a quick test
>>> directly through Python-a-mingw-us:
>>>
>>> Python 2.7.4 (default, Mar 18 2013, 12:04:44) [gcc] on win32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import wx
>>> >>> app = wx.App(redirect=True)
>>> >>> top = wx.Frame(None, title="PyCrust Helper",size=(800,300))
>>> >>> import wx.py.crust
>>> >>> cframe = wx.py.crust.CrustFrame(parent = top)
>>> >>> top.Show()
>>> >>> cframe.Show()
>>> >>> app.MainLoop()
>>>
>>> PyCrust crashes as soon as you focus on it. So this can at least be
>>> debugged without KiCad sitting ontop.
>>>
>>> PyCrust has worked previously with PyCrust because I've used it. So this
>>> problem shouldn't be too bad to solve.
>>>
>>>  Thanks again.
>>>
>>> Best Regards, Brian.
>>>
>>>
>> The STC sample in the wxPython build (From the wxWidgets library, i.e.
>> the cpp sample) behaves exactly the same, hanging on focus. I need to fix
>> the wxWidgets-cmake project.
>>
>> I'm on the case and a fix should arrive in our inbox shortly! Probably
>> just got some compiler definitions wrong or something.
>>
>> Best Regards, Brian.
>>
>>
> Fixed! I'll release updated versions tomorrow (It takes a while to build
> all the different versions and upload them to Launchpad!)
>
> That means that KiCad build is fully successful as far as I've tested so
> far.
>
> We just need to sort out the readline module in Python-a-mingw-us.I'd like
> to add the FindPythonLibs.cmake modules and what-not to that project too,
> and do a debug version along with a source tarball. Then people can debug
> their python modules through the python interpreter itself too. That really
> helps when you're writing a module in C. I'll include an example module in
> the install too.
>
> Best Regards, Brian.
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>

Follow ups

References