kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/02/2012 08:52 AM, Wayne Stambaugh wrote:
> On 11/2/2012 6:21 AM, Brian Sidebotham wrote:
>> On 31 October 2012 06:16, Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx
>> <mailto:miguelangel@xxxxxxx>> wrote:
>>
>>     Hi Brian, I'm not sure how dependent is wxPython on Cairo, if it's
>>     recommended as '0' but they enable it,
>>     may by it's needed. But it's just a feeling, 0-knowledge.
>>
>>     Do you have some branch for this that I could replicate and play
>>     around to figure out what's happening?
>>     or it's tested manually at the moment?
>>
>>     Also a binary package (with some debug info) could do the trick for me
>>
>>     I'd like to trace that wxpython init call down, and find where does
>>     it stop (and why).
>>
>>     Thanks a lot for your effort,
>>
>>     Mike,
>>
>>
>> Hi Mike,
>> I had to stop looking at the build for a while, but I should get another
>> chance to look at it earlier next week. It would seem that we need to
>> compile Python with MinGW, and wxPython.
>>
>> I had a quick look at the source for Inkscape and they have a separate
>> repository which includes a pre-built python for Windows which gets
>> included with their installer. They do not have it as a build process
>> for building Inkscape though, only as a separate pre-built binary:
>> https://launchpad.net/inkscape-devlibs
>>
>> I suspect this may have to be the route that KiCad goes down in order to
>> package the new scripting functionality. At least it means that we can
>> totally control the python version on Windows.
>>
>> I don't have a branch, but maybe I should create one. It is likely there
>> will have to be changes in order to build scripting support for Windows.
>> Even the find_package( stuff uses the registry (yuck!) entries to
>> discover where python is located and this will always be wrong because
>> we are using MinGW to build the KiCad binaries, not MSVC which the
>> standard python install is built with.
>>
>> Best Regards, Brian.
> Brian,
>
> I wanted to respond to this a few days ago but I had a system hard drive 
> failure and I've spent all week recovering my development system.  You 
> shouldn't have to build Python and wxPython from source with MinGW to 
> get this to work.  The MinGW version of GCC can link to MSVC libraries. 
>   You have to create the library link file using pexports which is an 
> optional part of MinGW.  The instructions on how to do this can be found 
> here: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs.  I've created 
> Python libraries this way so I know this works.  I would think as long 
> as you are using the same version of wxPython and wxWidgets you should 
> be OK.  The tricky part may be making sure to include all of the library 
> dependencies for wxWidgets, wxPython, and Python the installer.  I 
> assuming that you would want to just include a stand alone copy of 
> Python similar to the bazaar windows installer rather than download and 
> install Python and have the user deal with path issues.  I plan on 
> trying to build the KiCad python scripting from source over the next few 
> days.  If I manage do discover anything useful, I will pass that 
> information along to you.
>
> Wayne


Windows does have a common ABI for calling DLL's which should be compiler vendor agnostic,
at least for C code.  C++ will offer different name mangling strategies to trip on.

Getting static libraries to come in is slightly more difficult because of potential static
library file formats. 

But the ABI for passing parameters in registers and on the stack should be unified between
VC and Mingw, for functions declared as DLL entrypoints.

Dick