kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 16 February 2015 at 14:17, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> Brian,
>
> How are you telling the kicad configuration where wxPython build is
> located during you winbuilder configuration?  Would Garth's solution
> below solve your problem?  The only issue I see with Garth's solution is
> that if you install wxPython somewhere other than where you defined
> PYTHON_SITE_PACKAGE_PATH, you would be right back to where you started.
>  In other words you could build kicad but when you launched the python
> console, it would most likely crash because wxPython would not be
> located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
> wxPython would be loaded.

Hi Wayne,

First off, I just had a look and this is an easy fix; In the
environment I set up for building KiCad I just need to add the
wxpython base dir to the PYTHONPATH. Easy peasy. I will roll a new
version of KiCad-Winbuilder to fix this and also the dependencies of
the keyword lexers are now correct so parallel build jobs can be used
for the first compilation of KiCad too, so there are a few fixes that
can be released. I need to bump wxPython up now too.

Currently, I just point wxWidgets_ROOT_DIR to the root directory of
the wxpython-cmake archive (I won't call it an install because it's
just a decompressed release from https://launchpad.net/wxwidgets-cmake
). This has previously been enough to complete the build.

If we wind the clock back to when wxPython was being integrated with
KiCad life was different to what it is now. wxPython and Python on
Windows were both built using MSVC. The official distributions still
are of course. Dick made the commendable effort of providing a CMake
system for building Python with gcc on Windows, so this meant we could
link against libpython and pass around FILE* objects without fear of
the dreaded C-Runtime version mismatch crashes.

After that, I did the same for wxPython because the gcc build using
python on Windows was completely broke. That's not surprising as I
just said, gcc python modules couldn't be linked to libpython after
v2.4 ( or thereabouts ).

Those two projects got us everything we needed to link against
wxPython and produce a working KiCad with python scripting on Windows.
KiCad-Winbuilder became the testbed for it, in part to make sure the
Windows install was going to be valid.

Because of the MSVC compilation of the official distributions of
Python and wxPython we cannot use pre-installed versions and
pragmatically enable wxPython support as far as I know. Hence, KiCad
will have to bundle its own local Python and wxPython install that it
was linked against. Hence, there's no need to worry about crossing
over versions.

Boost is really the same, generally on Windows it's only available
officially as an MSVC compiled target.

It's very much safest to build and link everything with the same
compiler, ensuring that the ABI and C-Runtime remain constant across
the whole build. These days I think these packages are available in a
format we can use elsewhere, but they certainly weren't at the time.
We had a load of problems with C-Runtime versioning and also C++ DLL
ABI changes (That's just compiling with different versions of gcc!)

These days however packages like mingw-w64-python2 exist and so really
we should be able to make use of that in KiCad-Winbuilder instead of
the custom projects. I'll look into it.

Sorry for the long diatribe!

> I appreciate that you are providing external builders and I'm not trying
> to make your life miserable.  Although I'm sure at times it must seem
> that way.  I'm trying to find robust solutions for configuring and
> building kicad.  I wish we had never gone down the download_foo path,
> even for Boost.  It has been a tremendous support burden and a constant
> source of headaches.  We should have provided separate external builders
> for each dependency for problem the problem child platforms (OSX and
> windows) and kept the kicad source build configuration clean of any
> dependency building.  Hindsight is always 20/20.  The more I have to
> deal with this issue, the more I'm inclined to rip out all of the
> dependency build stuff once and for all.  It probably wont happen for
> the next stable release but it's priority continues to move up my todo
> list for the next development cycle.

No problem, don't worry about it too much. Everything is a moving
target. Wait until Windows 10 is out! ;)

I think the only thing that should be absolute is whatever clever
package searching we do is to provide a *_ROOT_DIR= be provided for
all packages we're using.

Certainly what we did have in mind were projects similar to the
https://launchpad.net/inkscape-devlibs project. That way, if anyone
wants to get developing KiCad fast they can grab the devlibs project
to satisfy all dependencies.

Sorry for the long email!

Best Regards,

Brian.