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