kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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