← Back to team overview

kicad-developers team mailing list archive

Re: Python scripting cmake build macros.

 

On 1/16/2013 12:16 PM, Miguel Angel Ajo Pelayo wrote:
> Other option we could have right now is compile out the wxpython support and provide
> only embedded python scripting + python pcbnew module for windows users.
> 
> In that case, next functionalities are lost:
> 
> 1) PyCrust shell inside pcbnew
> 2) Ability to create and run own wx-uis in the embedded python scripting.
> 
> And we keep:
> 
> 3) pcbnew module for commandline python scripting
> 4) embedded pcbnew wizards & plugins
> 
> Wayne, could you document the steps you followed until now so I can try to reproduce it and fight a little bit in this war ?

Please see my response to Adam.  I'll add the Pthon command line
scripting build instructions for Windows using MinGW to
Documentation/compiling/COMPILING.txt in my next commit.

> 
> 
> Miguel Angel Ajo
> http://www.nbee.es
> +34911407752
> skype: ajoajoajo
> 
> On 16/01/2013, at 18:09, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
> 
>> On 1/15/2013 1:38 PM, Dick Hollenbeck wrote:
>>> On 01/15/2013 12:28 PM, Wayne Stambaugh wrote:
>>>> On 1/15/2013 10:16 AM, Wayne Stambaugh wrote:
>>>>> On 1/15/2013 9:33 AM, Dick Hollenbeck wrote:
>>>>>> On 01/15/2013 08:10 AM, Wayne Stambaugh wrote:
>>>>>>> On 1/14/2013 10:15 PM, Dick Hollenbeck wrote:
>>>>>>>> On Jan 14, 2013 8:27 PM, "Dick Hollenbeck" <dick@xxxxxxxxxxx
>>>>>>>> <mailto:dick@xxxxxxxxxxx>> wrote:
>>>>>>>>> I want to simplify the conversation and refer to these needed items as
>>>>>>>> windows "packages".
>>>>>>>>> Python
>>>>>>>>> Python-dev
>>>>>>>>> WxPython
>>>>>>>>> WxPython-dev
>>>>>>>> WxWidgets
>>>>>>>> WxWidgets-dev
>>>>>>> wxPython-dev includes wxWidgets-dev so it should work fine for KiCad
>>>>>>> builds without scripting as well.  It should just be a matter of
>>>>>>> creating the MinGW linker stubs to the MSVC built libraries provided by
>>>>>>> the wxPython-dev package.  The only caveat may be if there is any name
>>>>>>> mangling issues between the two linkers. 
>>>>>>
>>>>>> We were reminded recently that stub libraries can use ordinals instead of names.
>>>>>>
>>>>>> As long as the DLL entry points follow the Windows DLL ABI  for argument passing and stack
>>>>>> cleanup, then it is in theory possible.
>>>>>>
>>>>>> With so many competing ABIs on Windows, it is also in possible that somebody screwed up
>>>>>> when building the pre-built DLLs, and you won't notice it until you bring in the second
>>>>>> compiler technology, i.e. Mingw.
>>>>>>
>>>>>> In that case it might mean building the DLLs yourself, instead of repackaging standard
>>>>>> ones.  And at that point you'd want to kick some ass, just to make somebody pay for their
>>>>>> disregard for the rest of the [non-Microsoft] world.
>>>>> Trust me, it's way past that already.  This has been a complete exercise
>>>>> in frustration.  It really shouldn't be this difficult.
>>>> The problem I am having with the MinGW build of wxPython is described at
>>>> the end of the the following thread:
>>>>
>>>> https://groups.google.com/forum/?fromgroups=#!topic/wxpython-users/brmQH4FSCo4
>>>>
>>>> I confirmed that both msvcrt and msvcr90 are being linked to all of the
>>>> wxPython extension files.
>>>>
>>>> Below is an explanation of the differences between the MS runtime libraries.
>>>>
>>>> http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx
>>>>
>>>> There are several solutions but none of them are attractive.
>>>>
>>>> 1) Rebuild Python with one of the express versions MSVC and link against
>>>> msvcrt instead of the MSVC specific version.
>>>>
>>>> 2) Rebuild mingw10.dll and link against the same msvcr??.dll as the
>>>> installed Python is build against.
>>>>
>>>> 3) Do as the thread above discussed and modify Python distutils to
>>>> ignore the version of msvcr??.dll that Python is linked against.
>>>>
>>>> 4) Figure out how to build Python with MinGW.  See the following link to
>>>> get an idea of how much of a task that will be.
>>>>
>>>> http://bugs.python.org/issue10504
>>>>
>>>> 5) Fix KiCad to build with the correct version of the free (as in beer)
>>>> express version of MSVC used to build Python.
>>>>
>>>> 6) Run around the room screaming and pulling out what is left of your hair.
>>>>
>>>> At this point, my desire to see this through has dropped substantially.
>>>> In the near term, I'll just use Linux when I need to do scripting.  I
>>>> will continue to chip away at it but don't expect a solution any time
>>>> soon.  If anyone has a better idea, I'm open to suggestion.
>>>
>>>
>>> Yeah, somebody could actually pay for it.
>>
>> I'm more than OK with that:)  It's just disappointing that we cannot
>> provide our Window's users with scripting support without such a huge
>> effort.
>>
>>>
>>> Expertise and time like this is not free,  and this is a case where opensource fails to
>>> clear this hurdle without funding.
>>>
>>> Notice I did not volunteer, it cannot be free.
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> 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