On 16 February 2015 at 14:17, Wayne Stambaugh <stambau...@gmail.com> 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp