kicad-developers team mailing list archive
Mailing list archive
Re: Python support -- SWIG and what about lua?
Tim Hanson <tim@...>
Sun, 12 Aug 2007 13:27:46 -0400
Icedove 220.127.116.11 (X11/20070607)
I agree. I've used SWIG in a large C++ program with embedded python, and it was mostly not worth
the effort; we had to keep around some perl scripts to make the generated SWIG code & headers mesh
with the rest of the compile. not at all clean. That said, I don't know anything about boost.python
(other than that boost itself is quite huge - is this true for boost.python?)
I have tried Lua and it is great (for an embedded scripting language) compared to python! small,
lightweight, simple, designed to be embedded, and no excess junk functionality. I also tried Java
(like Dick H), and it was a bit of a pain - but that was 4 years ago so I'm no expert. Lua has wx
For the python support to be complete, we need to develop a bridge
into the C++ classes BOARD, MODULE, and 12 or so other classes. After
that, a person could use python to write import and export scripts,
BOM scripts, and font size change scripts, and complete UI extensions.
this seems sweet to me. if there is a clever way to automate bridge construction in the code (so to
speak), then all the better!
DELIZY Florian wrote:
> I looked into the existing python support today. It did not seem
> complete, and unless I don't understand something, it was less than
> 15% complete.
Well, I didn't have time to submit it to svn sorry :)
> So I ask:
> 1) whether we want to support Python?
Yes, I am on it
> 2) if yes, should we consider using SWIG instead of Boost.Python?
> I think SWIG might be better for this project, because:
> A) wxPython is based on swig, and wxPython is part of the kicad to
> python solution. If SWIG is good enough for wxPyton, it would be good
> enough for KICAD-python.
Yes, but that's not a concern
> B) Boost.Python may be a bigger tool, but the build environment is
> overkill and probably harder to get working on both Windows and Linux.
Not true boost.python is multiplatform
> C) If we use, SWIG, we can get bindings to other languages besides
> Python, such as Java.
You'll still have to write code for that case
> D) The resultant SWIG binaries are easier to distribute if SWIG is
> used: they are smaller and there is distutil to install them into a
> python environment.
The resultant of boost is statically linked, and so is definitely
faster/easier/smaller than SWIG
- SWIG is a real pain to interface with
- SWIG makes use of its own build system
- You always have to re-build SWIG as part of your dev process
- SWIG uses a self language (not C++) to describe interface
and some more I forgot ...
> Scope of Work
> For the python support to be complete, we need to develop a bridge
> into the C++ classes BOARD, MODULE, and 12 or so other classes. After
> that, a person could use python to write import and export scripts,
> BOM scripts, and font size change scripts, and complete UI extensions.
> I am in favor of it, and could get it done, but I don't have the time
> to do it now, (if I were only retired, or funded...).
> Is the original developer of the python interface still around and
> interested and capable?
Right now working on it :)