kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

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 ?


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