Best Scripting Language for Embedded Work?
auriocus at gmx.de
Wed Jul 10 09:03:54 CEST 2013
you have multi-posted this to comp.lang.tcl. Please don't do that - use
crossposting and a proper follow-up (as I did now)
Am 10.07.13 03:29, schrieb David T. Ashley:
> We develop embedded software for 32-bit micros using Windows as the
> development platform.
Robert's answer made me hesitate - what exactly is your platform? Are
you writing the scripts for the embedded platform, or for Windows, or
does the embedded controller run Windows RT or something like this?
> We are seeking a general purpose scripting language to automate
> certain tasks, like cleaning out certain directories of certain types
> of files in preparation for ZIP'ing, generating certain source files
> automatically, etc.
> Selection criteria:
> a)Should be able to compile the script interpreter as a monolithic
> executable (no .DLL dependencies, etc.) for easy versioning and
> distribution of the script interpreter. (Note that I'm not asking
> that the script be a single executable, just the interpreter. To run
> a script you'd need both the script and the interpreter. The script
> would be a text file, and the interpreter would be a single .EXE.)
You are referring to tclkits. Yes, it's indeed possible to compile Tcl
into a statically linked binary, and C extension packages can be
statically linked, too. But tclkits are cheating: There are some files
like the standard library (i.e. init.tcl, the clock command etc.,
unicode encondings...) which are packed into a database and attached to
the tclkit. The tclkit then opens itself via the file system to read
these files. I don't know if this is possible in a typical embedded
system. If you are really talking about Windows, no issue.
Python has similar capabilities, look for pyinstaller or py2exe.
> b)Should be extensible, in that one could add commands or library
> functions to the script interpreter in C (for efficiency), and the
> whole script interpreter could again consist of a single executable
> with no other dependencies. (Note that I'm not asking that the script
> be a single executable, just the interpreter. To run a script you'd
> need both the script and the interpreter. The script would be a text
> file, and the interpreter would be a single .EXE.)
That is possible in Tcl using static packages. In Python I don't know,
but I think it should be possible.
> c)Should be able to spawn compilers and capture the output, do file
> I/O, and all the other minor expected stuff.
no real issue
> d)Graphical capability would be nice.
For GUI Python relies on either Tcl/Tk, wxwidgets, QT, GTK... I think it
is possible to assemble these into a packaged binary, too. However it
will be a rather large thing in the end.
> I know that Tcl/Tk would do all of the above, but what about Python?
> Any other alternatives?
I think Tcl/Tk is a really good match, especially if you are trying to
do GUI, which is very easy there. Also most scripting stuff is available
out of the box. Another option might be Lua
Very compact (a static binary is about ~200K), clean synatx, relatively
fast. OTOH, the standard library is of course not so extensive as for
Tcl or Python.
Bash is also an option, because it is some kind of standard for
scripting. But on Windows it seems alien and you'd need something like
MobaXTerm to get it into a single file.
More information about the Python-list