kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

Thanks a lot Wayne, 

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 16/01/2013, at 18:56, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:

> 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
>> 
>> 
>