kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

> 
> 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.
> 
>> 
>> Thanks for the fix!!
> 
> Your welcome.  It might take me another day or so to get this all sorted out but I'll get there.  Once I get this part of it working, the next task is to figure out how get the wxPython scripting part of it working which will likely be a lot more involved.  My primary motivation to get Python scripting working is to create pick-n-place report files for auto-insertion machines.  It makes more sense to me to use a scripting language to generate the files than C++.
> 

Wow, that's a great usage. :-)

> Wayne
> 
>> 
>> Enviado desde un móvil
>> 
>> El 12/01/2013, a las 18:15, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> escribió:
>> 
>>> I've been attempting to resolve my Python scripting build issues on MinGW32 on Windows and I have a few questions for the folks who wrote the cmake build code.  Why are we not using cmake's FindPythonInterp() instead of specifying the python executable on the path?  Specifying the Python interpreter on the command line at build time seems unnecessary to me.  CMake's FindPythonInterp supports defining a a specific version of Python by defining Python_ADDITIONAL_VERSIONS.  I'm guessing we would want to do that because python2 is currently defined as the default Python interpreter so I'm also assuming that the scripting code generated does not work with Python3.
>>> 
>>> There is also a link bug on MinGW because rt is defined as one of the link libraries in SWIG_LINK_LIBRARIES.  Actually, someone attempted to fix it by adding and conditional statement to only add rt on Linux but they forgot to take it out of the original list.
>>> 
>>> For future reference the indentation level for CMake files is 4 spaces and CMake statements should be lower case.
>>> 
>>> If no one objects, I will fix these issues which should make the Python scripting builds more reliable.
>>> 
>>> Thank you for all your efforts in bringing scripting to KiCad.
>>> 
>>> Wayne
>>> 
>>> _______________________________________________
>>> 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
>> 
>