kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 08/31/2013 09:23 AM, Brian Sidebotham wrote:
> 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?

Can the Python-a-mingw-us build script be used to build a local version
of Python to use as part of KiCad similar to what some of the other
projects (Blender, FreeCAD, Bazaar, etc.) provide for their Windows
builds?  I've been wanting to give it a try without have to remove my
existing Python installation.  By the way, thank you for a heck of
effort.  When I originally looked at this I knew it was going to more
time than I could handle.

Wayne

> 
> 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.
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp