> > 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 <[email protected]> >> 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
