Ergänzende Script-Sprache zum Build Prozess

"altbackenes Image" von Perl? Ist das deine persönliche Meinung oder 
behauptet es nur jemand in deinem Umfeld, der die Sprache vielleicht 
überhaupt nicht kennt?

Was die Intention zur Entwicklung von Perl war kann man auf den 
einschlägigen Seiten nachlesen.

Mit Perl kann man sehr gut Textdateien verarbeiten. Dafür wurde Perl 
auch geschaffen. Da Du es ja genau dafür nutzt, solltest Du Perl und 
Python auf dieser Ebene vergleichen.

Kannst du deine Anforderungen mit Python genauso effektiv umsetzen? Wie 
viel der Perl Funktionalität nutzt Du?

Ich persönlich nutze Perl für verschiedene Gelegenheiten. Ich rufe sogar 
Perl aus C/C++/Objective-C/Java Programmen auf um mir die aufwendige 
Implementierungen zu sparen.

Grüsse

> "altbackenes Image" von Perl? Ist das deine persönliche Meinung
> oder behauptet es nur jemand in deinem Umfeld, der die Sprache
> vielleicht überhaupt nicht kennt?

Du hast es richtig geahnt: Das beahupten Leute in meinem Umfeld. 
Mindestens einer davon kennt Perl mit Sicherheit sehr gut.

> Kannst du deine Anforderungen mit Python genauso effektiv umsetzen?

Noch nicht, ich muss Python erst lernen. Aber da komme ich langfristig 
warscheinlich sowieso nicht drum herum, weil mein Chef Python liebt. 
Dieses Webserver Projekt werde ich wohl nicht mehr ändern (never change 
a running System). Die Überlegung zum Wechsel bezieht sich eher auf 
künftige Projekte, wo ich eigene Anwendungsspezifische Pre-Compiler 
benötige.

> Da wäre eine kompilierte .exe das Mittel der Wahl.

Ja, aber die fuinktioniert dann nicht unter Linux. Die Installation von 
Strawberry Perl ist jedoch ein Kinderspiel, deswegen hatte ich Perl 
gewählt.

Ich will aber auch nicht zur Installation von Perl zwingen, wenn das 
veralteter Käse ist (was ich nur vermute).

Braucht man wirklich nur die perl.exe?

Unter Linux sind sowohl Perl als auch Python in der Regel 
vorinstalliert. Auch MAC OS enthält beide Sprachen standardmäßig, soweit 
ich weiss. Sind also nur die Windows User genervt.

Ist Python DER Nachfolger von Perl, oder ist das Quatsch?

> weil mein Chef Python liebt
Ist zwar kein rationales Argument aber für dich in Stein gemeisselt. ;-)
Kenne ich auch. :-P

> Die Überlegung zum Wechsel bezieht sich eher auf künftige Projekte
Dann kannst Du dir natürlich die nötige Funktionalität nach deinen 
Vorstellungen Implementieren. Mach dich über vorhandene 
Module/Bibliotheken schlau. Da sind bestimmt einige Interessante für 
dich dabei.

Grüsse

Stefan Frings schrieb:
> Ist Python DER Nachfolger von Perl, oder ist das Quatsch?

Nein, beide sind reichlich eigenständig nebeneinander.  Ich benutze
beides, wobei ich Perl zugegebenermaßen viel besser kenne als Python
und daher in den meisten Fällen die jeweilige Aufgabe damit schneller
erledigt habe.  Für den Großteil der Aufgaben sind beide meist
gleichermaßen brauchbar.

Python ist etwas für Leute, die bei der Perl-Syntax einen Knoten im
Kopf bekommen und stattdessen kein Problem haben, Leerzeichen als
signifikante Elemente einer Programmiersprache zu akzeptieren. :-))

Da du ja offensichtlich mit der Perl-Syntax keine Problem hast, spielt
dieser Teil jedoch für dich keine Geige.

Der einzig pragmatische Grund, der in deinem Fall für Python spricht
ist, dass es irgendeine Möglichkeit gibt, aus einem Python-Script
ein self contained Windows-.exe zu basteln, mit dem du deine
Windowsianer beglücken kannst, ohne dass sie ein komplettes Python
erst installiert haben müssen.  Für Perl ist mir etwas Vergleichbares
gerade nicht bekannt.

> Ist Python DER Nachfolger von Perl, oder ist das Quatsch?
Nein, Ja

Perl wurde als Tool zur einfachen Auswertung von Reporting files wie 
System Logging Dateien entwickelt. Die aktuellen Versionen wurden dann 
erweitert.

Python ist ein Programmiersprache wie C/C++/Java/….
Nur die Fantasie/Zeit/Kosten des Softwareentwicklers begrenzt deren 
Einsatzbereich. ;-)

> stattdessen kein Problem haben, Leerzeichen als signifikante Elemente einer 
Programmiersprache zu akzeptieren. :-))
Dafür hat man TABS als Teil des Syntax. Da kann man nur beten, dass 
einem nicht die Formatierung flöten geht.

Grüsse

Wenn man dem Tiobe-Index glauben darf (ist natürlich auch nur eine von
vielen Statistiken), kommt Perl tatsächlich so langsam aus der Mode
zugunsten von Python, Ruby, Lua usw.:

  http://www.tiobe.com/index.php/paperinfo/tpci/
  http://www.tiobe.com/index.php/paperinfo/tpci/Perl.html
  http://www.tiobe.com/index.php/paperinfo/tpci/Python.html

Das heißt aber noch lange nicht, dass man es nicht mehr benutzen sollte,
denn weiterentwickelt wird es nach wie vor.

In Python lassen sich die meisten Dinge ähnlich elegant realisieren wie
in Perl. Dabei ist die Python-Syntax weniger "unix-like", was für viele
Neueinsteiger als Vorteil gesehen wird. Aber nur wegen der Syntax und
weil Python (22 Jahre) ein wenig jünger als Perl (26 Jahre) ist, würde
dafür keine bestehenden Entwicklungen über den Haufen schmeißen.

Um bei deinem Web-Server-Projekt den Windows-Usern nicht die Installa-
tion von zusätzlichen Tools zumuten zu müssen, könntest du dein Konver-
tierungsskript auch in Bash schreiben. Die Bash ist m.W. beim AVR-GCC-
Paket für Windows mit dabei und ist auf Linux-PCs und Macs sowieso
vorhanden.

Die Bash liegt altersmäßig zwischen Perl und Python und ist laut
Tiobe-Index in den letzten Jahren ganz stark im Kommen:

  http://www.tiobe.com/index.php/paperinfo/tpci/Bash.html  ;-)

Ich benutze auf Arbeit perl2exe, ist zwar nicht kostenlos (125 Euro oder 
so) macht aber genau was Du braucht, eine exe für Computer auf denen 
kein Perl  läuft. Bei uns war das Problem, dass ein anderes 
Programmpaket bereits ein kastriertes Perl mitgebracht hat und bei 
paralleler Installation von Strawberry Perl die Arbeit verweigerte. 
Diese Probleme zu lösen wäre sicherlich teurer geworden (Zeitaufwand) 
als Perl2exe zu kaufen.

Jörg

Danke für eure Antworten.

Ich werde mal versuchen, einfach die perl.exe mit ins Projekt zu packen. 
Da mein Script keine Module verwendet, klingt das vielversprechend.

Ich gehe gerade ein Python Tutorial durch - nur so aus neugier. Am 
Anfange dachte ich noch "schön, endlich keine Klammern mehr tippen". 
Aber inzwischen erinnere mich an fehlerhafte Java und C++ Konstrukte, 
die gerade deswegen nicht richtig funktionierten. Beispiel gefällig?

1

for (int i=0; i<10; i++)

2

  j=i+100;

3

  System.out.println(j);

Python wäre hier so nett, sich an der Einrückung zu orientieren. Aber 
wer manchmal Klammer falsch setzt, der wird auch bei Einrückungen Fehler 
machen, fürchte ich.

Damit gewinnt man wohl nichts, außer ein paar Tastenanschläge zu sparen.

Die Art und Weise wie Python Objekte behandelt geht ja gar nicht! Da 
kann ich ja gleich in C programmieren.

Insgesamt kommt mir die Sprache noch mehr "Quick and Dirty" vor, als 
Java. Beispiel gefällig?:

1

class Auto:

2

    raeder=4

3

    def klaue_rad(self):

4

        self.raeder-=1

5

6

a=Auto()

7

a.pommes="3 Tüten"

Wieso zum Henker kann ich dem Auto drei Tüten Pommes unterjubeln ohne 
dass ein entsprechendes Attributes deklariert ist? Das ist doch Kacke, 
das provoziert doch Fehler ohne Ende. Der Intepreter merkt ja nichtmal 
Tippfehler (z.B. räder statt raeder). Und Kapselung war den Python 
leuten wohl auch so fremd, dass sie es einfach mal weg gelassen haben 
(von wegen private Attribute).

Ich bleibe bei Perl, Python ist Käse. Früher war alles besser :-)

Stefan Frings schrieb:
> Wieso zum Henker kann ich dem Auto drei Tüten Pommes unterjubeln ohne
> dass ein entsprechendes Attributes deklariert ist?

Das kannst du doch bei einem realen Auto auch, wenn du damit in den
Drive-In fährst. Und das, obwohl die wenigsten Autos einen speziellen
Pommestütenhalter eingebaut haben ;-)

Viele Python- und Ruby-Programmierer empfinden dieses "Open-Class"-
Konzept nicht als Nachteil, sondern als Vorteil. Siehe auch

  http://en.wikipedia.org/wiki/Monkey_patch

Ich selber mache von dieser Möglichkeit auch nur selten Gebrauch, aber
gerade beim Debuggen ist sie oft eine große Hilfe, da man einer Klasse
oder einem Objekt nachträglich nicht nur Membervariablen, sondern auch
Memberfunktionen hinzufügen kann. Dazu möchte ich aber nicht im Biblio-
thekscode herumpfuschen.

> Der Intepreter merkt ja nichtmal Tippfehler (z.B. räder statt raeder).

Ist das nicht bei den meisten Skriptsprachen so? Man verzichtet halt auf
die meisten Deklarationen (was weniger stupide Tipparbeit bedeutet),
verliert aber auf der anderen Site auch die Redundanz, die zur frühzei-
tigen Aufdeckung von Programmierfehler beitragen könnte.

Wie sieht denn das in Perl aus? Da kann man doch mit Datentypen und
Variablennamen auch beliebig viel Schindluder treiben, oder?

Bei der Programmierung wenig komplexer Tools (wie bspw. deinem HTML-
nach-C-Konverter) sind meist weniger Restriktionen besser als mehr, weil
man dadurch schneller zu einem lauffähigen Ergebnis kommt. Große
Anwendungen hingegen werden aus gutem Grund seltener in Python, Ruby
oder Perl, sondern meist in C++ oder Java implementiert. Ich finde es
schön, dass es beide Alternativen zum Aussuchen gibt :)

Es gibt übrigens auch Programmiersprachen, die die Vorteile von geringer
Redundanz im Quellcode (wenig Deklarationen u.ä.) mit denen einer sehr
strengen Compilezeitprüfung verbinden. Haskell gehört beispielsweise
dazu. Haskell-Quellcode ist oft ähnlich kurz wie entsprechender Python-
oder Perl-Code. Trotzdem bleiben nach erfolgreicher Kompilierung i.Allg.
deutlich weniger unentdeckte Fehler übrig als bspw. in Java oder C#.

> Früher war alles besser :-)

Fast alles ;-)

Wenn man perl gewohnt ist, wirkt Python schon oft sehr geschwätzig und 
einengend. unter diesem Aspekt ein wenig wie C vs. Pascal. Das hat so 
seine Vor- und Nachteile.
perl hat schon eine starke angediegene Tendenz zum write-only-Code. 
Python sträubt sich dagegen etwas mehr.
Es bleibt im Wesentlichen Geschmackssache.
+1 für perl. Und vi ;)

Leider reicht es wohl nicht, nur die perl.exe ins Projekt zu kopieren 
(zumindest bei Strawberry Perl). Aber das war ja gar nicht mein 
Haupt-Anliegen.

Ich habe nun verstanden, dass ich Perl und Python als Alternativen 
betrachten kann. Perl ist nicht veraltet.

Sehr lustig finde ich, wie weit unten PL/SQL steht. Das ist zwar nicht 
mein Haupt-Arbeitsmittel aber zweifellos unverzichtbar an meinem 
Arbeitsplatz. ABer zurück zum Hobby:

> Wie sieht denn das in Perl aus? Da kann man doch mit Datentypen
> und Variablennamen auch beliebig viel Schindluder treiben, oder?

Ja sicher. Ich hatte gehofft, dass Python sich hier "besser" verhält, 
wobei ich alles als besser empfinde, was weniger Magie im Hintergrund 
betreibt. Mit C, C++ und Java fühle ich mich deutlich wohler. Wobei ich 
die "Magie" von Java (Garbage Collector) schon grenzwertig finde.

Fazit: Es scheint keinen vernünftigen Grund zu geben, von Perl auf 
Python umzusteigen.

Danke Peter. Bei der Perl Version von ActiveState genügen zwei Dateien, 
die perl.exe und die perl516.dll.

Yalu X. schrieb:
>> Der Intepreter merkt ja nichtmal Tippfehler (z.B. räder statt raeder).

> Ist das nicht bei den meisten Skriptsprachen so? [...]

> Wie sieht denn das in Perl aus?

By default auch in Perl, aber jedes Perl-Programm, das nicht nur
direkt auf der Kommandozeile mit -e eingegeben oder fix in /tmp
geschrieben wird, hat als erstes wohl stehen:

use strict;
use warnings;

“use strict” bewirkt dabei einen Compilerfehler, wenn man versucht,
eine nicht explizit deklarierte Variable anzulegen.

Dadurch hat man, wenn's schnell gehen soll (und kurzlebiger write-only
code ist), die volle Flexibilität, aber trotzdem die Möglichkeit,
durch den Compiler auf saubere Deklaration achten zu lassen.

Aber das nur am Rande.  Ich denke, dass die eigentliche Programmier-
sprache für den TE nicht entscheidend ist, sondern eher der Weg, wie
er das alles bequem für seine Nutzer verpacken kann.  Unleserliche
Programme kann man sowieso in jeder Programmiersprache schreiben,
oder mit anderen Worten: “Real programmers can write FORTRAN in any
language.” ;-)

Jasch schrieb:
> [..] signifikanter Whitespace, was muss man rauchen um
> auf so eine Idee zu kommen?

Das make manual!?

SCNR ;-)

Jasch schrieb:
> Und Python, naja, ist wohl was auf Englisch "aquired taste"
> genannt wird, signifikanter Whitespace, was muss man rauchen um auf so
> eine Idee zu kommen?

Python hat die Quellcodestrukturierung mittels Einrückung nicht
"erfunden". Die Idee wurde bereits 1965 in dem Artikel "The Next 700
Programming Languages" von P. J. Landin erstmals veröffentlicht.

Mittlerweile wird dieses Konzept von immer mehr Programmiersprachen
umgesetzt. Beispiele gibt es hier:

  http://en.wikipedia.org/wiki/Off-side_rule

Einige der genannten Sprachen folgen allerdings auch Landins Vorschlag,
alternativ eine Strukturierung durch konventionelle Methoden wie
Interpunktion zuzulassen. So können bspw. in Haskell alternativ (oder
zusätzlich) zur Einrückung wie in C geschweifte Klammern und Semikola
verwendet werden. Weil das aber äußerst hässlich aussieht und auch der
Lesbarkeit nicht sehr zuträglich ist, wird von dieser Möglichkeit
praktisch nur in automatisch generiertem Quellcode Gebrauch gemacht.

In Python gibt es diese Alternative nicht. Eine Spracherweiterung, die
mit

1

from __future__ import braces

aktiviert werden kann, erweckt zwar die Hoffnung, dass in einer der
nächsten Sprachversionen diese Alternative eingeführt werden könnte.
Diese Hoffnung wird aber sofort wieder zunichte gemacht, denn der obige
Import wird prompt mit

1

SyntaxError: not a chance

quittiert :D

Bleibt also nur, den Programmcode immer ordentlich einzurücken, dann
wird man die fehlenden Klammern auch nicht vermissen :)

Und komischerweise kritisieren die meisten, die die Strukturierung durch
Einrückung ablehnen, auch die konsequente Strukturierung durch Klammern,
wie sie in Lisp stattfindet.

Yalu X. schrieb:
> In Python gibt es diese Alternative nicht.

Was praktisch einen "schnellen Einzeiler" (auf der Kommandozeile)
bis auf ganz wenige Trivialaufgaben unmöglich macht.

In Perl nutze ich diese Möglichkeit schon hin und wieder einmal,
wenn ich eine einmalige Aufgabe genau jetzt lösen muss, ohne dass
ich davon ausgehe, dass ich das morgen oder übermorgen nochmal
gebrauchen kann.

Markus M. schrieb:
> "altbackenes Image" von Perl? Ist das deine persönliche Meinung oder
> behauptet es nur jemand in deinem Umfeld, der die Sprache vielleicht
> überhaupt nicht kennt?

Die IT ist eine Mode Branche. Ich bleib bei den Klassikern wie dem 
eleganten "kleinen Schwarzen" alias C und dem "grauen Sakko" alias JAVA. 
Und für's grobe gibt's das klassische "Flanellhemd" alias Shell gewürzt 
mit awk und sed.

Wir programmieren hauptsächlich in C/C++ mit Bevorzugung von C++, wenn 
es das Zielsystem zulässt.

Für Tools zur Built-automatisierung, Datenkonvertierung, 
Quellcodegenerierung und auch kleinere Anwendungen  (Beispiel Remote 
Update und Überwachung von Systemen) benutzen wir Python.

Ich habe mir vor der Entscheidung für Python viele Scriptsprachen 
angeschaut. Obwohl mir die Leerzeichen als Syntaxelement erst unorthodox 
erschien und ich die Freizügigkeit  z.B. in Klassen direkt reinschreiben 
zu dürfen als Risiko gesehen habe, gefiel mir die konsequente 
Objektorientierung und die vielen bereits eingebauten und sonst 
verfügbaren Bibliotheken.
Auch die Performance ist gut, wenn auch mit C++ nicht zu vergleichen. 
Und dass man C++ sowohl einbinden als auch Python Code von C++ aufrufen 
kann, hat so manches Test Framework vereinfacht und manches C++ Programm 
mit Skripting versüßt.

Ich habe meine damalige Entscheidung nie bereut. Es sind viele gute 
Tools entstanden, die in C++ 3 mal so lange gedauert hätten. Ein 
Paradebeispiel ist ein Codegenerator, der beliebig komplexe und 
geschachtelte UML State Machines in sauberen, human readable C++ 
Quellcode übersetzt. Allein was wir dadurch an Unit Tests sparen ist 
enorm. Und für den funktionalen Test gibt es Python Test scripts, die 
die Requirements durch Aufruf und Stimulierung des C++ automatisch 
abtesten und einen schicken HTML Report erzeugen. Ich kann mir heute 
keine bessere Scriptsprache vorstellen. Ich schaue mir viele Dinge an, 
aber die Eleganz von Python (natürlich nur wenn man es diszipliniert 
einsetzt)  ist für mich ungeschlagen.

for i in range(1000):
   print "I AM A PYTHON LOVER!"

Pfingstliche Grüße
Michael

> Heh, gibt es eigentlich schon eine global gültige Einigung bezüglich der
> Breite eines Tabs wenn er in Leerzeichen umgewandelt werden soll bzw.
> umgekehrt? Nein? Sag ich doch.

Wer Tabs benutzt ist selber Schuld an den auftretenden Problemen.
Man kann heute jeden Texteditor so einstellen, dass er Spaces statt Tabs 
einfügt.

Man sollte ohnehin viel Gebrauch von Leerzeichen machen, um die 
Lesbarkeit zu erhöhen und und Folge die Fehlerrate zu senken.

A=17
MyFirstName="Michael"
MyFavoriteLanguage="PYTHON"
B=19

sieht tabellarisch (ohne Tabs) einfach übersichtlicher aus und Fehler 
gehen nicht im Zeichensalat unter.

A                  = 17
MyFirstName        = "Michael"
MyFavoriteLanguage = "PYTHON"
B                  = 19

Die Idee, das Hilfsprogramm mit dem C Compiler zu erzeugen, klingt 
erstmal gut. Sie scheitert aber daran, dass es ein Crss-Compiler für AVR 
Mikrocontroller ist. Der kann keine Programme für Linux/Windows/Mac OS 
erzeugen.

Unter Linux und Mac OS ist der C Compiler meist schon installiert, und 
wenn nicht, dann sehr leicht installierbar. Unter Windows sieht das 
schon ganz anders aus.

Wenn ich wüsste, wie man mit der Bash Shell Binärdateien in C-Quelltext 
(Arrays von Bytes) übersetzen kann, dann würde ich das tun. Für Windows 
würde ich dann ein Äquivalentes Basic Script schreiben.

Jasch schrieb:
> [...]
>> Mir fällt da spontan Python als Alternative ein.
>>
>> Würdet ihr lieber Perl Scripte oder Python Scripte verwenden?
>
> Weder noch. Für beides muss ich irgendwelche zusätzlichen Dinge
> installieren um ganz und gar simple Dinge (und nur im Buildprozess!) tun
> zu können. Und Python, naja, ist wohl was auf Englisch "aquired taste"
> genannt wird, signifikanter Whitespace, was muss man rauchen um auf so
> eine Idee zu kommen?

Ich habe nie verstanden, warum da so viele ein Problem damit haben. Hast 
du einen so schlechten und inkonsistenten Einrückungsstil, daß das für 
dich so problematisch ist? Wenn man richtig einrückt, passt doch alles 
ganz automatisch.

Jasch schrieb:
> Python und Konsorten sind in der Hinsicht einfach nicht robust gegenüber
> (nicht immer kontrollierbaren) Änderungen an scheinbar irrelevanten
> Details - immer daran denken, Quellcode ist oft bloss "Text" und da
> spielt die Anzahl führender Leerzeichen nach Ansicht Vieler keine
> signifikante Rolle. Python-Code z.B. per Mail zu verschicken kann ganz
> schön böse enden, während C-Code das vielleicht sogar überlebt.

Wenn's bei C-Code die Einrückung durch ein schlechtes Mail-Programm 
zerhackstückt hat, funktioniert er zwar evtl. noch, ist aber auch sehr 
schlecht lesbar. Im Zweifelsfall schickt man's halt per Anhang.

> Heh, gibt es eigentlich schon eine global gültige Einigung bezüglich der
> Breite eines Tabs wenn er in Leerzeichen umgewandelt werden soll bzw.
> umgekehrt? Nein? Sag ich doch.

Also ein Argument für python. Wenn da einer anfängt, wild Tabs und 
Leerzeichen zu mischen, bekommt er vom Interpreter eine Fehlermeldung, 
bis er das behoben hat.

Stefan Frings schrieb:
> Unter Linux und Mac OS ist der C Compiler meist schon installiert, und
> wenn nicht, dann sehr leicht installierbar. Unter Windows sieht das
> schon ganz anders aus.

Gleiches gilt aber auch für einen perl- oder python-Interpreter.

> Wenn ich wüsste, wie man mit der Bash Shell Binärdateien in C-Quelltext
> (Arrays von Bytes) übersetzen kann, dann würde ich das tun. Für Windows
> würde ich dann ein Äquivalentes Basic Script schreiben.

Also alles doppelt machen, damit man nix zusätzlich installieren muß?

Jasch schrieb:
> Etwas Redundanz ist nicht immer schlecht, denke ich.

Was für Redundanz? Ich hab schon genügend Code gesehen, bei dem sich die 
Struktur des Codes anhand der Einrückung ganz anders liest als anhand 
der Klammern. Während der Programmierer eher die Einrückung zur 
Erkennung nutzt, geht der C-Compiler aber ausschließlich nach den 
Klammern. Deshalb bekomme ich in so einem Fall einfach nur verwirrenden 
Code.
Bei Python ist die Einrückung gezwungenermaßen konsistent mit der 
Codestruktur, was ich als großen Vorteil empfinde und nicht wie 
scheinbar die meisten anderen als das große Ausschlusskriterium, die 
Sprache überhaupt zu nutzen.

Stefan Frings schrieb:
> Unter Linux und Mac OS ist der C Compiler meist schon installiert, und
> wenn nicht, dann sehr leicht installierbar. Unter Windows sieht das
> schon ganz anders aus.

Stimmt, aber für solche exotischen Entwicklerfeindlichen Plattformen g 
kann man auch ein fertiges Kompilat des dann in C, C++, ... schreibbaren 
Tools mitliefern.

> Wenn ich wüsste, wie man mit der Bash Shell Binärdateien in C-Quelltext
> (Arrays von Bytes) übersetzen kann, dann würde ich das tun. Für Windows
> würde ich dann ein Äquivalentes Basic Script schreiben.

Wie findet eigentlich die Umwandlung statt?
Wird der Input ohne jede Änderung als Array bereitgestellt um dann in 
die Firmware gelinkt zu werden? Dann brauchst du eigentlich nichts außer 
avr-objcopy:

Beispiel für Sound, ist aber egal was drin steckt:

1

%.o: %.pcm

2

        avr-objcopy -I binary -O elf32-avr -B avr --rename-section .data=.text $< $@

durch das --rename-section .data=.text landen die Daten im Flash. Sollen 
sie ins SRAM, einfach das Renaming weglassen.

Verwenden kannst du die Daten dann mit:

1

extern uint8_t _binary_filename_extension_start[];

2

extern uint8_t _binary_filename_extension_end[];

ggFs. um PROGMEM bzw. __flash ergänzt oder zumindest im Code 
entsprechend verwendet.

Alles andere erledigt der Linker. Ich hab das oben als Array gemacht, 
weil es so direkt geklappt hatte. Pointer wäre logischer, funktioniert 
aber wenn ich mich recht entsinne nicht, weil die Indirektion eben nicht 
sein darf. Also du erhältst zwei Symbole: _binaray_*_start und 
_binary_*_end für jedes so eingelinkte objcopy-Ergebnis, wobei das * 
sich nach dem Dateinamen richtet, mit nicht-C-Identifier-gerechten 
Zeichen transformiert zu einem Unterstrich.

Stefan Frings schrieb:
> Wenn ich wüsste, wie man mit der Bash Shell Binärdateien in C-Quelltext
> (Arrays von Bytes) übersetzen kann, dann würde ich das tun.

Ich habe dein Perl-Skript makefsdata mal in ein Bash-Skript übersetzt.
Es ist nicht intensiv getestet, aber bis auf die Reihenfolge der
einzelnen Arrays scheint das gleiche Ergebnis herauszukommen.

Der Unterschied kommt daher, dass die Bash beim Durchwandern eines
Verzeichnisses die Dateinamen alphabetisch sortiert, Perl aber
offensichtlich nicht. Die Reihenfolge der Arrays in der verketteten
Liste und der Listenanker (HTTPD_FS_ROOT) sind daher ebenfalls anders,
aber in sich wieder konsistent.

In deinem Skript werden die Variablennamen aus den Dateinamen durch
Ersetzen von Slashes und Punkten durch Underscores generiert. In meinem
Bash-Skript werden zusätzlich auch Leerzeichen durch Underscores
ersetzt. Sonstige Sonderzeichen, die in Variablennamen nicht zulässig
sind, werden allerdings auch hier nicht berücksichtigt.

> Für Windows würde ich dann ein Äquivalentes Basic Script schreiben.

Da das Bash-Skript außer der Bash selber keine weiteren Unix-Tools
benötigt, müsste es bei Vorhandensein einer Bash ohne Änderungen unter
beliebigen Betriebssystemen laufen. Schau mal, ob das AtmelStudio die
Bash nicht vielleicht schon enthält. Bei WinAVR war sie jedenfalls noch
mit dabei.

@Malte: Vielen Dank für Deinen Tip mit objcopy. Ich brauche allerdings 
noch ein Inhaltsverzeichnis, also eine Liste der Dateinamen zusammen mit 
Zeigern auf die Dateien. Ansonsten gefällt mir Dein Ansatz prima, den 
kann ich sicher woanders gebrauchen. Vielleicht tippe ich die Dateinamen 
manuell ein und verweise dann auf die mit objcopy erzeugten Daten.

@Yalu: Da WinAVR (und die AVR Toolchain) eine Bash enthalten und die 
gleiche Shell in Linux und Mac OS enthalten ist, gefällt mir dieser 
Lösungsansatz ganz besonders.

Die Unterschiedliche Reihenfolge der Dateien und die etwas andere 
Behandlung von Leerzeichen sind für das Projekt kein Problem. Denn die 
Dateinamen in meinem Projekt enthalten keine Sonderzeichen. Ich staune 
gerade, dass die Bash Dateien byteweise lesen kann. Bisher dachte ich, 
dass es gerade daran scheitern würde.

Leider klappt es (noch) nicht unter Windows mit WinAVR:

C:\Dokumente und Einstellungen\Administrator\Eigene 
Dateien\NET-IO-Modul_v2.11.1
0\v2.11.10 2013-03-30\src> sh bashmakefsdata
bashmakefsdata: shopt: globstar: unknown shell option name
bashmakefsdata: varnames: bad array subscript

Schade, diese Bash (v2.0.4 bäääh, ist ja uralt!) kann wohl nicht alles, 
was wir brauchen.

Wenn ich die Ersetzung von Zeichen in Dateinamen und die 
Ausschlussregeln für unerwünschte Dateien entferne, funktioniert das 
Script prinzipiell. += gibt auch nicht, aber das leicht zu ersetzen.

Leider scheitert es an dem read Befehl. Die Version von WinAVR kann 
nämlich keine Binärdaten lesen.

Aber das macht nichts, dafür haben wir ja objcopy, wie ich gerade 
gelernt habe. Ich schreibe das Script so um, dass damit nur das 
Inhaltsverzechnis erzeugt wird und auf die Daten referenziert wird, die 
objcopy erzeugt.

Stefan Frings schrieb:
> Ich staune gerade, dass die Bash Dateien byteweise lesen kann. Bisher
> dachte ich, dass es gerade daran scheitern würde.

Es geht, allerdings musste ich eine ganze Weile herumfrickeln, um read
dazu zu bringen, wirklich jedes Zeichen ohne irgendwelche Konvertie-
rungen zu lesen. Mit -N1 (kleines 'n' richt nicht), -r, LC_ALL=C und
IFS= scheint es aber zu passen.

> bashmakefsdata: shopt: globstar: unknown shell option name

Das gibt es erst in Version 4 und erlaubt es, mit '**' bei der Filename-
Expansion auch Unterverzeichnisse mit einzubeziehen. Alternativ könnte
man es auch wie in deinem Perl-Skript machen oder ein externes Tool wie
find (sofern verfügbar) verwenden.

> bashmakefsdata: varnames: bad array subscript

Das kommt wahrscheinlich vom Array-Index -1 (Zugriff auf das letzte
Array-Element, ebenfalls ab Version 4) in der drittletzten Zeile. Du
kannst ihn einfach durch $i ersetzen, da i von der letzten Schleife noch
den passenden Wert enthält.

Version 2.0.4 hört sich aber so alt an, dass da durchaus noch ein paar
andere Dinge fehlen könnten.

Stefan Frings schrieb:
> Leider scheitert es an dem read Befehl. Die Version von WinAVR kann
> nämlich keine Binärdaten lesen.

Falls die Installation ein Hexdump-Tool (z.B. od) enthält, könnte man
dieses die binären Bytes in Hex-Zahlen konvertieren lassen, die dann
problemlos mit read gelesen werden können. Die Formatierung mit
printf braucht man dann auch nicht, da man zwischen den gelesenen
Hex-Zahlen nur noch die Kommata und Linefeeds einfügen muss.

Ansonsten führt Google mit den Stichworten

  bash read binary file

zu weiteren Vorschlägen.

> Aber das macht nichts, dafür haben wir ja objcopy

Oder so :)

Jasch schrieb:
> Das hast Du falsch verstanden. Ich persönlich habe damit kein Problem,
> auch weil es mein Editor praktisch automatisch für micht tut (All hail
> Emacs!). Natürlich nicht für Python, da lässt sich das ja nicht
> automatisieren(!).

Warum sollte das nicht gehen? Die Zeile vor einer eingerückten endet 
immer mit einem Doppelpunkt. Und eine Einrückungsebene zurück geht man 
halt mit einer entsprechenden Tastenkombination oder zur Not mit einer 
(an der Stelle eh sinnvollen) Leerzeile. Das ist dann auch nicht mehr zu 
tippen als mit geschweiften Klammern.

Jasch schrieb:
>> Also ein Argument für python. Wenn da einer anfängt, wild Tabs und
>> Leerzeichen zu mischen, bekommt er vom Interpreter eine Fehlermeldung,
>> bis er das behoben hat.
>
> Ja, würde ich im Prinzip zustimmen. Bloss ist es in der Praxis so dass
> a) Python Tabs akzeptiert (als 8 Spaces breit IMHO)

Ja, tatsächlich. Mir wäre es lieber, wenn eine Mischung aus Tabs und 
Spaces grunsätzlich zum Fehler führt, und ich dachte auch, das sei so. 
Hab's nur nie gemerkt, weil ich selbst keine Tabs verwende. Einen Tab 
fix als 8 Zeichen zu interpretieren, halte ich für eher unsinnig. Das 
heißt, daß die Umsetzung in Python nicht so gut ist, wie ich eigentlich 
erwartet hätte, aber das Konzept allgemein finde ich trotzdem sinnvoll.

> und b) man anderen Programmierern eher keine Vorschriften machen kann,
> diesbezüglich oder in jeder anderen Hinsicht. ;-)

Man muß ja keine Vorschriften bezüglich dem konkreten Einruckungsstil 
machen, sondern nur, daß er halt immer gleich ist.

Jasch schrieb:
>> Was für Redundanz? Ich hab schon genügend Code gesehen, bei dem sich die
>> Struktur des Codes anhand der Einrückung ganz anders liest als anhand
>> der Klammern.
>
> Dave Jones würde sagen "Trap for young players". Ja, bin ich auch schon
> drüber gestolpert, darum schätze ich Editoren die entsprechend der
> Syntax automatisch einrücken können. Sieht es nicht so aus wie ich
> erwarte - habe ich mich irgendwo vertippt.

Das ergibt sich ja bei Python gar nicht, weil die Einrückung Teil der 
Syntax ist. Es sieht für den Interpreter immer genau so aus wie für 
dich.

Jasch schrieb:
> Die Redundanz (wahrscheinlich ist das der falsche Begriff) ist übrigens
> zwischen Einrückung und geschweiften Klammern. Naja, nicht wirklich, die
> Klammern sind ja was in jedem Fall entscheidet.

Ja, genau das meinte ich. Deshalb ist es keine Redundanz. Es sieht nur 
redundant aus, aber der Compiler meckert nicht, wenn's nicht 
zusammenpasst.

Geheilter schrieb:
> Meine Meinung:
>
> a.) Wenn man Cross-Compiliert, hat man auch einen Host-Compiler

Das dürfte unter Linux der Normalfall sein, aber Windows-Benutzer müssen 
sich das erst immer noch umständlich extra runterladen und installieren.

> b.) Mit modernem C++ ist man praktisch genau so schnell, wie mit
> einer Script-Sprache.

Finde ich nicht. Files parsen und ähnliches, also vor allem 
Stringhandling und reguläre Ausdrücke finde ich mit einer Skriptsprache 
einfacher. C++ hat gerade erst eingebauten Support für reguläre 
Ausdrücke bekommen. Wenn man also nicht unbedingt die aktuellsten 
C++-Compiler voraussetzen will, muß man zusätzlich noch boost oder so 
installieren, um reguläre Ausdrücke zu haben. Ähnliches gilt selbst 
schon für so einfache Sachen wie z.B. Verzeichnisse.

> d.) Sprachen wie Python sind zu "fett". Alleine die verschiedenen
> Versionen und die verschiedenen Pakete.

Alles wesentliche, was man für die beim Buildprozess nötigen Dinge 
braucht, ist schon dabei, da braucht man keine Pakete. Und bei C++ 
gibt's nicht nur verschiedene Versionen, sondern vor allem noch ganz 
unterschiedliche APIs je nach System. Es sei denn, man installiert sich 
zusätzliche Pakete...

Rolf Magnus schrieb:
>> Ja, würde ich im Prinzip zustimmen. Bloss ist es in der Praxis so dass
>> a) Python Tabs akzeptiert (als 8 Spaces breit IMHO)
>
> Ja, tatsächlich. Mir wäre es lieber, wenn eine Mischung aus Tabs und
> Spaces grunsätzlich zum Fehler führt, und ich dachte auch, das sei so.

Da muss man zwischen Python 2 und Python 3 unterscheiden. Python 3
entspricht dabei eher deinen (und auch meinen) Vorstellungen, Python 2
nicht so sehr.

Python 2:

Ein Tab wird wie ein Sprung zur nächsten Spalte, die ein Vielfaches von
8 ist, behandelt. Wenn man also im Editor den Tabstop-Parameter auf 8
setzt und das Programm optisch richtig eingerückt ist, ist auch der
Compiler einverstanden. Wenn man als Tabstop-Parameter einen anderen
Wert als 8 einstellt, sieht der Code im Editor evtl. nach Kraut und
Rüben aus, wird aber trotzdem richtig ausgeführt.

Python 3:

Alle Zeilen eines Blocks müssen mit exakt der gleichen Kombination aus
Tabs und Leerzeichen beginnen. Ein untergeordneter Block (nach einem if,
while o.ä.) muss mit dem gleichen Whitespace wie der übergeordnete Block
plus mindenstens einem weiteren, an der rechten Seite hinzugefügten
Whitespace-Zeichen beginnen.

Dadurch ist gewährleistet, dass korrekter Code im Editor unabhängig von
der Tabstop-Einstellung immer konsistent aussieht, d.h.

- alle Zeilen eines Block sind gleich weit eingerückt und

- ein untergeordneter Block ist tiefer eingerückt der übergeordnete.

Folgende Einrückungen sind in Python 2 und 3 korrekt
(␣ = Leerzeichen, ⇥ = Tab):

1

␣      ⇥␣if a<0:

2

␣      ⇥␣␣     ⇥a = 0

3

␣      ⇥␣␣     ⇥b += 1

Folgende Einrückungen sind nur in Python 2 korrekt:

1

␣      ⇥␣if a<0:

2

       ⇥       ⇥a = 0   # Leerzeichen aus der Zeile darüber fehlen

3

␣      ⇥␣␣␣␣␣␣␣␣b += 1  # Tab wurde durch Leerzeichen ersetzt

Wird die obige Regel nicht korrekt umgesetzt, meckert der der Python-3-
Compiler

1

TabError: inconsistent use of tabs and spaces in indentation"

Python-Code, der nach den Python-3-Regeln richtig eingerückt ist, ist es
auch nach den Python-2-Regeln, umgekehrt aber nicht unbedingt.

Die Regeln in Python 3 sind strenger, aber logischer, da sie nicht von
einer angenommenen Tab-Weite abhängen.

Noch besser wäre es, die Tabs und damit sämtliche Einrückungsverwirrung
komplett aus der Sprachdefinition von Python zu verbannen. Vielleicht
kommt das ja in Python 4 :)

Rolf Magnus schrieb:
> Natürlich nicht für Python, da lässt sich das ja nicht
>> automatisieren(!).
>
> Warum sollte das nicht gehen?

Beim Neuschreiben geht's.  Wenn man aber Teile per copy & paste
woanders neu einrücken muss, geht es prinzipbedingt eben nicht
mehr automatisch.

Es ist schon seltsam, dass vermutlich jeder über Programmiersprachen
wie whitespace lächelt, aber eingefleischte Python-Programmierer
plötzlich signifikante Leerräume als etwas Sinnvolles reklamieren,
wenn es um "ihre" Sprache geht, während völlig selbstverständlich
die Syntax aller anderer Programmiersprachen natürlich großer Mist
ist.

Nein, ich komme mit Python so zurecht (mit Perl deshalb besser, weil
ich es länger kenne), aber auch wenn ich es benutzen kann (und manche
Sachen darin nicht unpraktisch finde), so würde ich trotzdem nicht
auf die Idee kommen, das dämliche Konzept der signifikanten Leerzeichen
irgendwie gut zu finden.  (Das der signifikanten TABs in make auch
nicht, aber dass die Mist sind, wusste man zumindest bei der Schöpfung
von Python bereits, man hätte den Fehler also nicht wiederholen
brauchen, statt ihn mit den Leerzeichen auf eine neue Stufe zu heben.)

Wenn mir ein C-Programm zu verhunzt aussieht, schicke ich es durch
indent oder den Emacs, bis es meinen Lesegewohnheiten entspricht.
Wenn mir ein Python-Programm zu verhunzt aussieht (und wir sind uns
einig, dass man verhunzte Programme in jeder Programmiersprache
hinbekommt), dann bleibt mir nur, es wegzuschmeißen.

Für den TE ist es aber vermutlich in der Tat die sinnvollste Variante,
mit objcopy aus den Binärdaten C-Code zu erzeugen und dann mit
normalen Shell-Bordmitteln ein zugehöriges Inhaltsverzeichnis.

Stefan Frings schrieb:
> in meinem Webserver Projekt (http://stefanfrings.de/avr_io/index.html)
> übersetze ich statische HTML Dateien und Bilder in C-Quelltext

Ich mache es auch so, halt mit einem kleinen selbstgeschriebenen
C-Tool. Eine Handvoll Makros für "<script type...>" etc. Das Tool
ist ins makefile eingebunden und erzeugt mir einfache Strings.
Sehr praktisch.

Grund: C kann ich - mit Perl habe ich noch nichts zu tun gehabt ;)

Ist zwar etwas offtopic, aber da der TE ja inzwischen für ihn zufrieden-
stellende Lösungen sein Problems erhalten hat, möchte ich doch noch
einmal kurz das Whitespace-Thema aufgreifen:

Jörg Wunsch schrieb:
> Es ist schon seltsam, dass vermutlich jeder über Programmiersprachen
> wie whitespace lächelt,

Was gibt es an Whitespace zu belächeln? :-/ ¹

> aber eingefleischte Python-Programmierer plötzlich signifikante
> Leerräume als etwas Sinnvolles reklamieren, wenn es um "ihre" Sprache
> geht, während völlig selbstverständlich die Syntax aller anderer
> Programmiersprachen natürlich großer Mist ist.

Naja, in den meisten Programmiersprachen sind Leerräume signifikant.
So auch bspw. in C:

1

int akt(char lotte);  //  mit Spaces: Funktionsdeklaration

2

intakt(charlotte);    // ohne Spaces: Funktionsaufruf

Ok, da kann man den Unterschied zwischen den beiden Zeilen noch gut
erkennen. Aber was ist hiermit:

1

void printUpToEightSpaces(int n) {

2

  // woran sieht man, dass der folgende String tatsächlich aus 8

3

  // Leerzeichen und nicht etwa aus einem Tab besteht?

4

  static char spcs[] = "        ";

5

6

  printf(spcs + sizeof spcs - 1 - n);

7

}

Auch der Linefeed (ein weiteres Whitespace-Zeichen) ist in vielen
Sprachen signifikant. Immerhin ist der Linefeed i.Allg. leicht als
solcher zu erkennen (kann allerdings auch mit dem Umbruch überlanger
Zeilen durch den Editor verwechselt werden).

In Python gibt es eben zusätzlich noch signifikanten Leerraum am
Zeilenbeginn. Böse wird es aber erst dann, wenn man Spaces unüberlegt
mit Tabs vermischt. Unüberlegte Tabs sind aber generell eine potentielle
Fehlerquelle (s. zweites C-Beispiel oben). Also sollte man doch eher
über die Tabs als über die signifikante Quellcodeeinrückung schimpfe :)

> (Das der signifikanten TABs in make auch nicht, […]

An Make stört mich nicht die verpflichtende Einrückung bei den Regeln,
sondern die Vorgabe, dass diese Einrückung mit einem Tab zu erfolgen
hat. Nachdem ich meinem Editor jegliche Verwendung von Tabs abgewöhnt
habe, muss ich nun in Make immer ein sehnenscheidenentzündungsförderndes
^V<TAB> tippen :-/

——————————
¹) s/:\(.\)\//;\1)/

Yalu X. schrieb:
> Nachdem ich meinem Editor jegliche Verwendung von Tabs abgewöhnt
> habe, muss ich nun in Make immer ein sehnenscheidenentzündungsförderndes
> ^V<TAB> tippen :-/

Falscher Editor. :-)

Jörg Wunsch schrieb:
> Falscher Editor. :-)

Ja, so wird es wohl sein.

Vielleicht ist aber auch nur die Konfiguration suboptimal. Da ich aber
recht selten neue Make-Regeln schreibe, ist wohl der Leidensdruck noch
nicht groß genug, der Sache auf den Grund zu gehen ;-)

Edit:

Mensch, jetzt hat's mir doch keine Ruhe gelassen. Eine einzige Zeile
(sogar ohne Einrückung) im Konfigurationsskript hat den Job getan. Dabei
musste nicht einmal TFM geRet werden :D

Yalu X. schrieb:
> Mensch, jetzt hat's mir doch keine Ruhe gelassen. Eine einzige Zeile
> (sogar ohne Einrückung) im Konfigurationsskript hat den Job getan.

Ja, schön.  Hätte mich im 3. Jahrtausend schon gewundert, wenn man
dem Editor nicht dateitypabhängige Regeln beibiegen könnte, und
dass Makefiles hard TABs brauchen, sollte so ziemlich jeder bessere
auch wissen.

Da ich gerade in den verschiedenen Opensource-Projekten mit allerlei
Mischmasch aus Leerzeichen und TABs konfrontiert bin, habe ich mir
für den Emacs mal irgendwann eingestellt, dass er mir hard TABs in
einer geringfügig anderen Farbe als der normalen Hintergrundfarbe
darstellt.  Damit kann man sie gut erkennen, und normalerweise
editiere ich dann die jeweiligen Dateien möglichst in der Form weiter,
wie sie bereits waren.

Was sich auch wirklich gut macht ist, den Editor "trailing whitespace"
deutlich sichtbar machen zu lassen.  Das ist 'ne richtige Seuche, die
da rumfleucht ...

@Yalu und @Malte:
Ich habe mich dazu entschlossen, mein Projekt unverändert zulassen und 
weiterhin das bewährte Perl Script zu verwenden. Nach dem Motto: Never 
change a running system. Für Windows packe ich eine die perl.exe mit ins 
Projektverzeichnis.

Aber ich konnte von euren Vorschlägen lernen und werde sie serh 
warscheinlich im nächsten Projekt anwenden, wenn ich nochmal 
Binärdateien in den Flash Speicher ablege.

PS: Mein Filesystem ist Kacke. Es verschwendet einige Bytes 
Speicherplatz, wie mir aufgefallen ist, weil die verkettete Liste mit 
den Pointern auf die Dateinamen und Datei-Inhalte im RAM liegt. Aber 
egal, es funktioniert. Nächstes mal mache ich es besser.

Stefan Frings schrieb:

> Ich habe mich dazu entschlossen, mein Projekt unverändert zulassen und
> weiterhin das bewährte Perl Script zu verwenden.

<seufz> Also doch noch ein Happy End!

> Nach dem Motto: Never change a running system.

Genau so.

> Für Windows packe ich eine die perl.exe mit ins Projektverzeichnis.

Würde ich nicht machen. Ich würde in README sinngemäß schreiben:
"Auf eine Entwicklermaschine gehört neben make und einem C Compiler 
selbstverständlich auch ein Perl Interpreter. Falls auf deiner Maschine 
kein solcher Interpreter installiert ist, dann bist du vermutlich auf 
Windows unterwegs <geheucheltes Beileid>. Einen Perl Interpreter kannst 
du dann hier <Link auf ActivePerl> herunterladen". Fertig.

XL


PS: vielleicht doch noch ein Wort zu Python vs. Perl. Auch ich bin 
bekennender Perlianer. Ich habe nicht prinzipiell etwas gegen Python, 
auch wenn ich das Konzept "Whitespace zur Strukturierung" grenzwertig 
finde. Vor allem kam Python für mich zu spät, es war YASL (yet another 
scripting languange). Irgendwann ist auch mal Schluß. Und im Gegensatz 
zu z.B. Ruby ist Python auch nicht signifikant sexier als Perl oder 
Shell (oder PHP oder awk und was man sonst als alter UNIXer noch kann, 
zugegebenermaßen habe ich sogar Lebenszeit an Tcl ver(sch)wendet).

Was mich außerdem nachdenklich stimmt, ist daß ich regelmäßig Probleme 
mit Programmen habe, die zwingend eine neue Python-Version haben wollen 
(der Klassiker für mich: bzr) und nicht dazu zu bewegen sind, mit einer 
älteren Version zu funktionieren. So etwas hatte ich mit Perl noch nie. 
Schlimmstenfalls braucht man da mal eine weitere Extension, aber ein 2 
oder 3 Jahre alter Interpreter war da noch nie ein Problem. Mittlerweile 
stehe ich auf dem Standpunkt, daß es ein gravierender Fehler war, bzr 
ausgerechnet in Python zu implementieren. Ein Interpeter mit längerer 
Halbwertszeit oder etwas kompiliertes wäre deutlich besser gewesen. Ich 
kann halt nicht jedesmal meine Entwicklermaschine umkrempeln bloß weil 
ein weiteres externes Projekt ein neueres bzr Repository-Format 
verwendet, das ein neueres bzr erfordert das ein neueres Python 
erfordert.

Axel Schwenke schrieb:
> zugegebenermaßen habe ich sogar Lebenszeit an Tcl ver(sch)wendet

Ich auch. ;-)  Kann man auch damit zurechtkommen, wenn's denn sein
muss.  Mfile ist beispielsweise damit geschrieben, und damit spannt
sich auch der Bogen zum TE: der einzige Grund, warum ich Mfile in
Tcl (+Tk) geschrieben habe war, dass es zusammen mit WinAVR
ausgeliefert werden können sollte und daher mit genau dem zurecht
kommen musste, was bei WinAVR (+ native Windows) ohnehin schon dabei
ist.  Das war eben weder Perl noch Python (dessen Hype damals ohnehin
noch nicht gestartet war), sondern Tcl, infolge des Insight-GDB-
Frontends.  Also habe ich Mfile in Tcl geschrieben, was soll's, man
kann es benutzen, und es hat ein paar Leuten geholfen, in der
Lernkurve die zusätzliche Aufgabe "Makefile erstellen" erstmal
aussparen zu können.