kicad-developers team mailing list archive

[Garth Corral <gcorral@xxxxxxxxx>]

Using PYTHON_SITE_PACKAGE_PATH is documented as being for this purpose, and it works on OS X because the libraries end up in the application bundle and all the paths are set up properly during the build and packaging.


From Documentation/compiling/build-config.txt:

…

PYTHON_SITE_PACKAGE_PATH (PATH)
-------------------------------
Default: System site library path

When building KiCad with Python scripting enable, the Python site library path
is used by default.  If you want to install the KiCad Python extension in a
different path, set this variable to the desired path.

…

So, there is a documented build config variable that is for the express purpose of doing this, but it is not honored when checking the result, which means that using this variable can now lead to failure even if it’s properly done.  This is an issue at least on OS X.  For the record, I’m not using .download_foo to build wxPython.  I simply build it and point the kicad build at it through this config variable.  It never needs to be “installed” system-wide.

Garth

> On Feb 16, 2015, at 7:42 AM, Brian Sidebotham <brian.sidebotham@xxxxxxxxx> wrote:
> 
> 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.
> 
> _______________________________________________
> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature