| Thread Previous • Date Previous • Date Next • Thread Next |
On 1/12/2013 3:05 PM, Miguel Angel wrote:
Thanks Wayne! It sounds superb, I tried to fix the rt problem, and got nowhere.. That means that you finally managed to build a windows pyd&pcbnew with scripting?
It took me a while to find it. It turns out that librt was always included as part of the link list define by SWIG_LINK_LIBRARIES. It was also being conditionally included for non-windows and non-osx builds. I just removed it from SWIG_LINK_LIBRARIES and it worked for both platforms. I see Dick already committed the fix so that part of it is taken care of. Thanks Dick.
Also the python2 thing was mine, mainly because I didn't find the cmake function to search for the python interpreter which is just perfect. Where did you find it? (I promise I read the cmake manual several times) :)
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? 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.
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++.
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
| Thread Previous • Date Previous • Date Next • Thread Next |
