← Back to team overview

kicad-developers team mailing list archive

Re: Python scripting cmake build macros.

 

On 1/14/2013 5:05 PM, Dick Hollenbeck wrote:

On Jan 14, 2013 3:59 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx
<mailto:stambaughw@xxxxxxxxxxx>> wrote:
 >
 > On 1/14/2013 3:12 AM, Miguel Angel Ajo Pelayo wrote:
 > > It's two different problems,
 > >
 > > 1) the fixswigimports.py fix the way swig (inside pcbnew.py) loads
 > > pcbnew.so/pyd <http://pcbnew.so/pyd> <http://pcbnew.so/pyd>
internally, the swig generated .py
 > > has problems to support "internal" (inside your own program) object
 > > bindings. It's documented, but not widespread used. We fix it to
make it
 > > work in both cases, when doing "import pcbnew" from inside an
 > > scripting-pcbnew  and when doing import pcbnew from
 > > standalone/commandline python.
 > >
 > > 2) At the time we started with scripting, I raised some discussion
about
 > > this topic, and thought that python2.x has more widespread library
 > > support (compared to python 3 advantages).
 >
 > I'll take a look at it and see if I can make the KiCad scripting work on
 > Python 2 & 3.  I may have to write some creative CMake code to get it to
 > work but it should be possible.
 >
 > I have a quick question regarding the KICAD_SCRIPTIN_WXPYTHON option.
 > When this option is enabled, is wxPython.h included in any of the SWIG
 > generated code.  I did quick grep of the scripting folders and didn't
 > see wxPython.h included anywhere so the only other place I can think
 > that it would end up is in the SWIG generated code.  If it's not, that
 > will make life a whole lot easier.  If it is, building wxPython on
 > Windows to install the development files is proving to be painful.

We talked about providing prebuilt [wx] python binaries.

I still plan on attacking the problem that way. Unfortunately and not unexpectedly, Windows is the problem child. You can install the prebuilt wxPython binaries from wxpython.org but the development files come in a separate installer and are not compatible with the MinGW binaries most developers already have built and installed on their Windows machines. This means forcing FindwxWidgets to ignore the MinGW build of the wxWidgets libraries and headers and use the prebuilt libraries and headers installed by the development installer. The other problem with the prebuilt libraries is they are built with MSVC so you have to create the library link files for MinGW to be able to link with KiCad. It's doable but it's not a trivial task and it's ugly.


 >
 > >
 > >
 > > It's also true, that, if we made the move now, and having phoenix in
 > > place, it could be less disruptive if we find ourselves forced to move
 > > into python3 at some moment in time.
 > >
 > > Anyway, that most probably would force us to move our wrappers into SIP
 > > and get the both "wrappings" (internal wrapping, external wrapping).
 > >
 > > I'm not really opposed to do it, or do some testing, but I'm really
 > > concerned about:
 > >
 > > 1) SIP support (no so widespread support at swig, that will let us work
 > > with other languages too)
 > > 2) SIP internal/external wrapping
 > > 3) Phoenix real support. (is it only a test branch or will it be
 > > supported in time?, it could also become the main branch at some
time..)
 >
 > Even if Phoenix becomes the default way to build wxPython, I see no
 > reason to switch from SWIG to SIP.  SWIG gives use the opportunity to
 > support other scripting languages.  SIP appears to be a Python only code
 > generator.
 >
 > > 4) My time has become a little scarce: I have challenging big projects
 > > for this year, and also a new (first) daughter, which I love, but
it's a
 > > time black hole 8]
 >
 > There is no better way to spend your time than with your family.
 >
 > >
 > >
 > > I think I dropped all my thoughts about the topic. :-)
 > >
 > >
 > >
 > >
 > > 2013/1/14 Dick Hollenbeck <dick@xxxxxxxxxxx
<mailto:dick@xxxxxxxxxxx> <mailto:dick@xxxxxxxxxxx
<mailto:dick@xxxxxxxxxxx>>>
 > >
 > >     On 01/13/2013 06:57 PM, Wayne Stambaugh wrote:
 > >     > On 1/13/2013 4:58 PM, Miguel Angel Ajo Pelayo wrote:
 > >     >>> The CMake module you were looking for is FindPythonInterp which
 > >     finds the Python interpreter and sets the PYTHON_EXECUTABLE
 > >     variable.  You can define a specific Python version by setting
 > >     PythonInterp_FIND_VERSION. I still have some validation to do on
 > >     Linux when both Python3 and Python2 are installed just to make sure
 > >     everything works as expected.
 > >     >>>
 > >     >>> Also found that using "#!/usr/bin/env python2" in
 > >     fixswigimports.py breaks the windows build so I am currently
working
 > >     on a solution to this problem.  I changed python2 to python and it
 > >     fixes the build on windows but may cause problems for Linux.  I'm
 > >     thinking since the python interpreter is being called to run this
 > >     script that the "#!/usr/bin/env python2" line is even necessary.
 > >     >>> Is there any reason to run this script outside of the KiCad
 > >     scripting build?
 > >     >> It's only needed when we make a scripting build and the
pcbnew.py
 > >     is regenerated. It will fix the way it looks for _pcbnew.so / .pyd
 > >     so when running from a pcbnew with embedded python, it won't
 > >     >> reload the DLL and use the internal swigs to pcbnew objects.
 > >     >>
 > >     >>> If not, then I should be able to safely remove this from
 > >     fixswigimports.py.  If it cannot be removed, I may have to use
CMake
 > >     to generate this file on the fly to add the correct Python
 > >     environment string to the beginning of the file.
 > >     >> May be we can just call $PYTHON_EXECUTABLE fixswigimports.py,
 > >     most probably this little script will run within python3, but
not sure.
 > >     > The last I recall is that code generated by SWIG is not yet
compatible
 > >     > with Python 3.  That's why Python 2 is still required to build
 > >     wxPython.
 > >     >   It's been a while since I've used SWIG so maybe that has
changed.
 > >     > Until I see a wxPython release built against Python 3, I'll
stick with
 > >     > Python 2.
 > >
 > >     Swig is there now:
 > >
 > > http://www.swig.org/Doc1.3/Python.html#Python_python3support
 > >
 > >     wxpython for python 3.x is known as Phoenix, and it is also
probably
 > >     build-able at this time.
 > >
 > >
 > >     But they did not do the interface to C++ in Phoenix using SWIG.
 > >
 > >
 > >
https://groups.google.com/forum/?fromgroups=#!topic/wxpython-users/p69PjUnMN-c
 > >
 > >     Used SIP instead:
 > >
 > > http://riverbankcomputing.co.uk/software/sip/intro
 > >
 > >     In any case it looks like python 3.x is an option, as it should be,
 > >     since its about 5
 > >     years old or more.
 > >
 > >
 > >
 > >
 > >
 > >
 > >     _______________________________________________
 > >     Mailing list: https://launchpad.net/~kicad-developers
 > >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
 > >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
 > >     Unsubscribe : https://launchpad.net/~kicad-developers
 > >     More help   : https://help.launchpad.net/ListHelp
 > >
 > >
 > >
 > >
 > > --
 > >
 > > Miguel Angel Ajo Pelayo
 > > http://www.nbee.es
 > > +34 636 52 25 69
 > > skype: ajoajoajo
 > >
 > >
 > > _______________________________________________
 > > 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




Follow ups

References