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 <[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
