← Back to team overview

kicad-developers team mailing list archive

Re: Python scripting cmake build macros.

 

On 1/14/2013 6:06 PM, Miguel Angel Ajo Pelayo wrote:

As usual, I forgot to hit Reply-all :-)

On 15/01/2013, at 00:04, Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx> wrote:



On 14/01/2013, at 22:59, Wayne Stambaugh <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> 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.

It might require also some work in initialization of the python engine (may be more),
because they are initialized in a different way. Python 2 initializes as an static interpreter
(only one for your process), and Python 3 initializes as an object, so you can have
many in interpreters in your project, also calls to python api could differ, but not sure.


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.


I don't understand exactly what you mean.

The include to wxpython It's outside the pcbnew directory in <kicadroot>/scripting/python_scripting.h,
the wxpython thing is used to be able to create widgets/dialogs from python that can be
referenced/used in C++, or the other way around. Also for the nice pycrust shell.

Sorry about the confusion. I don't know how I missed the wxPython.h include in python_scripting.h. I must have fat finger my grep statement. Thanks for help.





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.

I think you're right


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.

Everything must be kept in a balance :-)




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




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






References