kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/6/2014 11:37 AM, Brian Sidebotham wrote:
> On 5 October 2014 00:18, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> Here is a another teaser of the mingw64 version of kicad showing the
>> wxPython shell so it appears to be working.
>>
> 
> Hi Wayne,
> 
> There's no reason it shouldn't work really, KiCad-Winbuilder uses
> mingw-w64 and builds fine with wxPython (Well, the wxwidgets-cmake
> project I did for it: https://launchpad.net/wxwidgets-cmake ).

Did you try removing our custom FindPythonLibs.cmake file and run a
build?  If so I will either remove our custom version or copy the latest
version from CMake 3.0.2.

> 
> By the way, is the MSYS python okay when not being run in a POSIX
> environment? I'm sure it is and in which case it removes the need for
> Python-a-mingw-us, but Python-a-mingw-us is still the only MinGW
> compiled python distribution outside of MSYS as far as I'm aware. This
> is obviously essential for us when packaging KiCad for windows.

Yes!  It is a mingw64 or mingw32 build of Python depending on what you
install and build against.  It is not an msys build.  Msys2 really is
leaving the original msys/mingw32 project in the dust.  I don't see the
original project ever catching up.  The msys2 project uses the pacman
package manager from Arch linux.  It's almost like using a linux distro
inside of windows.  There is already a package file created for kicad.
The version the msys2 project started doesn't build yet but I already
have it building on my system.  I have to submit Tom's context patch to
them because the packaged version of boost 1.56 doesn't work and then I
have a few minor CMake fixes to verify.  Once I send the patches the
msys2 project, there will be a fully packaged version of kicad for
windows that can be install by typing `pacman -S
mingw-w64-x86_64-kicad`.  I just saw this morning that wxWidgets 3.0.2
was already packaged and it was just released today!  If you haven't
tried msys2 yet, give it try.

> 
> What we do need to think about when generating a stable release for
> Windows is the packaging of dependencies. Python brings with it a lot
> of dependency requirements. I don't think cpack will be able to handle
> our installer very well if we choose to include python (which I am
> assuming we will have to).

I'm hoping we can tweak our nsis installer script to pull in all of the
dependencies required to run a local version of python.  I realize that
it is a lot of work but I really think providing a local version of
Python will be a better way to go than any attempt to get the natively
installed Python (built with msvc) to play nice will applications
compiled with mingw.  I really would like to include python scripting on
Windows rather than making windows a second class citizen.

Wayne

> 
> I'm very glad to see you've got the python console up and running! :D
> 
> Best Regards,
> 
> Brian.
>