kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

Hi Guys,

I have got round to releasing some binaries for the wxwidgets-cmake project
( https://launchpad.net/wxwidgets-cmake )

I have produced two sets so far, wxWidgets 2.9.4 and wxPython 2.9.4. Both
sets are uncode, gcc_dll versions. The wxPython binaries are aimed at being
used by the KiCad project. The binaries are compatible with
FindwxWidgets.cmake so there are no changes needed in the detection of
wxWidgets as far as KiCad is concerned.

Python-a-mingw-us is used to build wxPython. The binary releases of
wxPython do not include libpython2.7.dll or any of the other python
dependencies, but perhaps it should actually?

Either way, python-a-mingw-us is required to build KiCad with scripting
support on Windows with MinGW. I have attached a patch for KiCad which will
correctly detect python-a-mingw us installation. I have modified the
standard FindPythonLibs.cmake module (and had to add in it's supporting
cmake modules) because I believe the MinGW checks in there are really
required, to at least trip people up who are trying to build incorrectly by
using MinGW to build python modules for the official distribution which is
flawed due to multiple C-Runtime linking problems.

I also wanted to use the functions for the Python-a-mingw-us project from
in the standard FindPythonLibs.cmake module for building a python module.
They look pretty cool and make an easy way of generating a cmake python
module.

KiCad-Winbuilder has been updated (not release) to build KiCad with python
scripting on Windows. This is successful bar two things:

(1) The PyCrust scripting console currently hangs when it gets focus with a
mouse click. This is probably related to a readline module bug in
Python-a-mingw-us which I will be looking at in the next few days.

(2) I get attribute errors when running either of the footprint wizards,
but the main body of code appears to be working, it just looks like some
API breakage or something.

So all in all, we're 90% there. There are some outstanding things to do:

(A) For those of you building with MSYS or *shudder* Cygwin,
wxwidgets-cmake will fail because wx-config is required. This is not yet
included because it is a templated system and requires a lot of variables
being setup correctly before being configured. This is on my list of TODO.

(B) The packaging needs thinking about somewhat. The KiCad-Winbuilder
script does a lot of copying of files now to the bin directory to get
everything in one place. I assume this is how we're thinking of structuring
the install directory of KiCad anyway on Windows?

Right, my wifes getting tetchy - I literally haven't left my keyboard for
two days. I can't wait to get this build in to the wild. It's so close now!!

Please have a look at the patch attached and let me know whether this is an
acceptable approach to supporting KiCad scripting on Windows in CMake. I
think it makes a lot of sense.

I altered PYTHON_INCLUDE_PATH to PYTHON_INCLUDE_DIRS because
PYTHON_INCLUDE_PATH is deprecated now.

Almost everything in the patch is the inclusion of a standard CMake module.
FindPythonLibs has been altered though to find Python-a-mingw-us when MINGW
is being used (Can cross-compile too if using ${PYTHON_ROOT_DIR} :) )

Oh, and HAVE_STDINT_H needs to be defined if it is available, otherwise
MinGW fails to correctly parse pyport.h on Windows.

Best Regards,

Brian.

Attachment: changes.diff
Description: Binary data