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" <[email protected] >>>>>> <mailto:[email protected]>> 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 : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
