kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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.

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.

Cheers,

Wayne

On 2/16/2015 7:11 AM, Brian Sidebotham wrote:
> This commit broke KiCad-Winbuilder because of the same reason as
> Garth. wxPython is not "installed" in the compilation environment. It
> gets installed by the build system. We will be installing wxPython
> locally to the KiCad installation on Windows, there's no other way to
> distribute it.
> 
> I haven't had time to investigate the issue at all, I've just seen bug
> reports against KiCad-Winbuilder to this effect. Most likely I can fix
> it in KiCad-Winbuilder.
> 
> Best Regards,
> 
> Brian.
> 
> 
> On 16 February 2015 at 01:39, Garth Corral <gcorral@xxxxxxxxx> wrote:
>> There is a variable that is already in use in CMakeLists.txt, PYTHON_SITE_PACKAGE_PATH, that can be used to point to an alternate library path.  I don’t know where this variable came from but I believe it was being used by KicadOSXbuilder for this purpose at one point.
>>
>> This (or something) just needs to be prepended to the path of the python performing the check.
>>
>> -        set( _py_cmd "import wxversion;print wxversion.checkInstalled('${_wxpy_version}')" )
>> +        set( _py_cmd "import sys;sys.path.insert(0, \"${PYTHON_SITE_PACKAGE_PATH}\");import wxversion;print wxversion.checkInstalled('${_wxpy_version}')" )
>>
>> This works for me but if anyones sees an issue with this please speak up.  If I got the quoting right then an unset PYTHON_SITE_PACKAGE_PATH would simply prepend an empty path and search the default sys.path as usual.
>>
>> Garth
>>
>>
>>> On Feb 15, 2015, at 4:55 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>
>>> On 2/15/2015 7:42 PM, Garth Corral wrote:
>>>> I’m pretty sure you do not understand what I’m saying.
>>>
>>> Perhaps you are right.  To better understand how you would use CMake to
>>> ensure the the correct version of wxPython is somewhere on you system
>>> and gets installed along with KiCad, please modify CMakeList.txt and
>>> send me a patch.  Maybe then I will understand how you would solve the
>>> problem.  Ignoring wxPython as a build dependency is not an option and
>>> neither is the download_foo ugliness that we currently have.  That
>>> should be moved to a higher level outside of the kicad source like
>>> kicad-winbuilder.
>>>
>>>>
>>>>
>>>>> On Feb 15, 2015, at 4:41 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>>
>>>>> On 2/15/2015 7:27 PM, Garth Corral wrote:
>>>>>> I think perhaps we’re having a miscommunication.  I don’t think it’s
>>>>>> thin ice at all to build a version of a dependency and then pointing my
>>>>>> kicad build at it.  I think it’s more of an issue to assume that
>>>>>> whatever is installed on your system is the right thing.  What if I
>>>>>> needed different versions of wxWidgets for other developement work and
>>>>>> also wanted to build kicad with a different version?  It seems perfectly
>>>>>> reasonable to build wxPython specifically for kicad.
>>>>>
>>>>> It is.  I do it all the time.  I build and install the latest versions
>>>>> wxPython, wxWidgets, Boost, etc. and set up my build environment to
>>>>> build kicad against these custom builds without touching my default
>>>>> system configuration.  The key action is the install and configure part.
>>>>> Just building the correct version of a dependency is not enough.
>>>>>
>>>>>>
>>>>>> I also think that the build time and runtime behavior are being
>>>>>> conflated.  There is nothing other than the version check that requires
>>>>>> wxPython to ‘run’ at build time.  Prior to this it was enough to build
>>>>>> it and put everything int the right place and then tell the python
>>>>>> interpreter where to look a runtime.  At least that’s what’s been
>>>>>> happening all along on OS X.
>>>>>
>>>>> This has been happening on all platform all along and it has bitten
>>>>> other devs because their wxWidgets and wxPythons version did not match
>>>>> causing pcbnew to crash.  There was even a bug report filed against it.
>>>>> That is why the change was made.
>>>>>
>>>>>>
>>>>>> This version check just assumes that it will be instaled on the system,
>>>>>> and I think that’s wrong.
>>>>>
>>>>> That's exactly what build configuration tools like CMake and autotools
>>>>> are designed for not just creating Makefiles.  Why would you even
>>>>> attempt to build any software if the prerequisites cannot be found on
>>>>> your system?  How would you even know if the software was correctly
>>>>> built?  You have been doing this manually except in the wrong order.
>>>>>
>>>>>>
>>>>>> Garth
>>>>>>
>>>>>> On Feb 15, 2015, at 4:16 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>>>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>>>>
>>>>>>> On 2/15/2015 7:06 PM, Garth Corral wrote:
>>>>>>>> Well, yes, you’ve sort of explained the problem.  Unless wxPython is
>>>>>>>> on the library path or using PYTHONPATH it isn’t going to work, and I
>>>>>>>> don’t have wxPython installed on my system for any other purpose.
>>>>>>>> So, invoking the system python as is done in the version check isn’t
>>>>>>>> going to work without first pointing it to a path that contains the
>>>>>>>> wxPython library.
>>>>>>>>
>>>>>>>> I’ve been building wxPython as part of my kicad builds and passing
>>>>>>>> -DPYTHON_SITE_PACKAGE_PATH to cmake with the built wxPython library.
>>>>>>>> Up to now this has worked for me.
>>>>>>>
>>>>>>> This should have never worked in the first place.  Would you expect
>>>>>>> kicad to build if a valid version of wxWidgets or Boost could not be
>>>>>>> found?  The build configuration should have always checked for a valid
>>>>>>> install of wxPython before allowing you to build kicad with
>>>>>>> -DKICAD_SCRIPTING_WXPYTHON=ON.  You will have to tell the python
>>>>>>> interpreter where wxPython is installed before you configure the kicad
>>>>>>> build.  I'm sorry for the inconvenience but you've been skating on thin
>>>>>>> ice with the previous behavior.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Garth
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Feb 15, 2015, at 3:54 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>>>>>>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>>>>>>
>>>>>>>>> I'm confused.  How else should this work?  If configure your kicad build
>>>>>>>>> to include wxPython, then one would expect the configuration to fail if
>>>>>>>>> wxPython is not installed or the correct version.  Irregardless of where
>>>>>>>>> wxPython is installed on your system, python still needs to know where
>>>>>>>>> it is installed before you can use it either by installing wxPython into
>>>>>>>>> your python library path, adding the path programmatically during python
>>>>>>>>> scripting initialization, or using PTYHONPATH.
>>>>>>>>>
>>>>>>>>> On 2/15/2015 6:39 PM, Garth Corral wrote:
>>>>>>>>>> I build wxPython as part of my kicad build.  So if you just invoke
>>>>>>>>>> python and do, import wxversion, it will fail with an import error
>>>>>>>>>> because it can’t find the module.  I’d need to set the python path
>>>>>>>>>> to point to my built wxPython.  When all is compiled and installed,
>>>>>>>>>> everything works because the libraries are moved into the right places.
>>>>>>>>>>
>>>>>>>>>> Garth
>>>>>>>>>>
>>>>>>>>>>> On Feb 15, 2015, at 3:36 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>>>>>>>>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> If you don't have wxPython installed, how are you compiling with
>>>>>>>>>>> KICAD_SCRIPTING_WXPYTHON=ON?  The wxPython configuration check and the
>>>>>>>>>>> python scripting version selection initialization only happen when you
>>>>>>>>>>> configure your build with KICAD_SCRIPTING_WXPYTHON=ON.
>>>>>>>>>>>
>>>>>>>>>>> On 2/15/2015 6:30 PM, Garth Corral wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hmm…  So, unless I’m missing something, the new wxPython version
>>>>>>>>>>>> check isn’t ever going to work for me.  I don’t have wxPython
>>>>>>>>>>>> installed as part of my system install so importing wxversion is
>>>>>>>>>>>> always going to fail unless I point it to my wxPython that I
>>>>>>>>>>>> build as part of my kicad builds.  Anyone else experiencing this?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Garth
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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
>>