Best Scripting Language for Embedded Work?
David T. Ashley
dashley at gmail.com
Fri Jul 12 03:14:35 CEST 2013
On Tue, 09 Jul 2013 21:44:48 -0400, Dave Angel <davea at davea.name>
>On 07/09/2013 09:29 PM, David T. Ashley wrote:
>> We develop embedded software for 32-bit micros using Windows as the
>> development platform.
>> 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.
>Oh, I thought you were going to run this on Windows. You're just
>developing it on Windows, and you want to cross-compile to target some
>other platform? Which?
Sorry, I wasn't very complete.
The scripts would run on Windows 7 only, but because they may generate
part of the source code for the embedded system, we have to be careful
about versioning the interpreter, and a monolithic executable makes
>> (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.)
>If you're also constraining your "program" to a single text file, you
>don't want Python. It uses modules, imported from your script to do
>much of the work.
>> 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.)
>And that's supposed to HELP efficiency??
Did I ever claim I wanted efficiency?
>> c)Should be able to spawn compilers and capture the output, do file
>> I/O, and all the other minor expected stuff.
>> d)Graphical capability would be nice.
>> I know that Tcl/Tk would do all of the above,
I was able to do this with Tcl/Tk years ago.
>I doubt it.
>> but what about Python?
>> Any other alternatives?
More information about the Python-list