kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

Hi Guys,

I was going to send this direct to Dick, but I think this pickles through
enough projects for it to be of use or concern for others too:

The Debug scripting builds are broken because something that includes the
Python header that has _DEBUG defined alters a LOT of defines. Linking will
fail with missing references all over the place where in a release build
the functions boil down to nothing in order to speed the interpreter up.

(1) Python-a-mingw-us Debug build changes

The debug build of python-a-mingw-us was a little broken. Looking at how
the standard Python build does a debug build means that all dynamically
loaded extensions must have the debug suffix ("_d"). This is required
because the import module searches for the import name with the debug
suffix.

The standard build also adds the debug suffix to libpython and the main
python exe.

I've changed the build to do this, and that works well.

The standard Python distribution doesn't really provide a debug build that
you can easily use. I'd like Python-a-mingw-us to provide a
developer-friendly debug build. We would also include "fixed" cmake modules
for discovering the python install to use the correct libraries.

As far as I'm aware the reason for having the debug suffix on all "C"
compiled parts of python is so that the debug and release versions can be
pasted ontop of each other and share the same install path. Use python_d to
use the debug enriched interpreter, and python for a speedy interpreter.

(2) wxPython-cmake build changes

The only fixes required to the wxPython-cmake project are to include the
fixed findpython*.cmake modules.

All dynamically loaded modules require the same python debug suffix for the
debug version of the build.

Nothing else exciting.

(3) KiCad build changes

Again, the findpython*.cmake files require further fixing. Really nothing
much tbh - at least to get a working build system.

The PCBNEW dynamically loaded module required the same python debug suffix
in debug builds.

We also need to add the _DEBUIG preprocessor directive; But I expect this
to change compilation on Linux and Mac.

Just getting the debug build working was enough to know that something was
wrong with the scripting console initialisation as I instantly got a
wxWidgets Debug Assert: AddPane() NULL window ptrs are not allowed...

It is strange - running through an IDE works okay, but running through gdb
or via the command line results in the assertion. The error message from
python says it cannot find _std_d.pyd - yet it is there and doesn't appear
to have any dependency problems. So I'm not sure why this is failing yet.
The clues as to what's up are clearly there, but I cannot piece them
together yet.

So I had some questions because there are a few options for us.

(a) We/I can complete the fixes I've detailed above. I've selected the
KiCad fix to only generate the debug python suffix on pcbnew.pyd on Windows
if it is a debug build.

(b) We can doctor Python-a-mingw-us to not append the debug suffix when
it's built as a debug m
oodule.

Q:

(i) Does anyone see any output from the PyErr_Print() calls? I think we
need to extract the error information ourselves and push the output
somewhere. Most likely we could do with a class called PyErr_PRINTER() or
something so this can be called after we run internal python strings or
files. I don't think we get any python error feedback at all at the moment.

(ii) What does Linux current do for debug builds? i.e. what python lib does
it link to? I expect the python library detection is infact wrong. On a
debug build it should detect the debug library. I've had to fix
FindPythonLibs and FindPythonInterp to find suffixed versions on debug
builds.

(iii) Does applying _DEBUG to Linux builds break them?

(iv) Is anyone else doing debug KiCad scripting builds on Windows?

KiCad-Winbuilder is nearly ready for release with scripting support, but I
need to fix the console issue described above and to also fix Debug builds
before I release.

Sorry this email's so long!!

Best Regards,

Brian.