← Back to team overview

kicad-developers team mailing list archive

Re: Python scripting cmake build macros.

 

It's two different problems,

1) the fixswigimports.py fix the way swig (inside pcbnew.py) loads
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).


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..)
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]


I think I dropped all my thoughts about the topic. :-)




2013/1/14 Dick Hollenbeck <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
> 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

Follow ups

References