kicad-developers team mailing list archive
Mailing list archive
Re: Python scripting cmake build macros.
On 1/14/2013 12:42 AM, Dick Hollenbeck wrote:
> 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:
> wxpython for python 3.x is known as Phoenix, and it is also probably build-able at this time.
I wonder why the wxPython folks haven't released a Python3 build yet
unless there are still some issues.
> But they did not do the interface to C++ in Phoenix using SWIG.
> Used SIP instead:
Thanks for the information. I'll take a look at it when I get a chance.
> In any case it looks like python 3.x is an option, as it should be, since its about 5
> years old or more.
For developers yes. For users probably not so much. I just checked
Debian's package archive and wxPython is still only available for
Python2 even in the unstable branch. Until wxPython binaries are widely
available for Python3 on all platforms, I think sticking with Python2
for now will save us a lot of grief.