python preprocessor für C/C++
-
BlackJack
@Manuelh87: Ich hatte bis jetzt in der Tat den Eindruck, dass Du Dir das mal eben so ausgedacht, aber nicht zuende gedacht hast. Und dann eben mal schnell was hingehackt, was nicht im Mindesten den schwierigen Teil Deiner Anforderungen erfüllt. Es wird ein Problem gelöst, das eigentlich keines ist, weil das noch mit dem C-Präprozessor erledigt werden könnte. Und das auch noch mit absolut gruseligem Python-Quelltext.
Wieso sollte aus dem Umstand, dass die Alarmglocken schrillen wenn man seine eigene Template-Engine, sein eigenes Buildsystem oder VCS schreiben will, unmittelbar daraus folgen, dass es diese Dinge nicht gibt!? Gerade *weil* es sie schon gibt, sollte man sich gut überlegen das Rad noch einmal zu erfinden.
Python-Code in C eingebettet ist nicht leichter nachzuvollziehen als das extern zu machen. Das Syntax-Highlighting stimmt nicht, oder immer nur für eine der Sprachen. Und man muss den Python-Quelltext im C-Quelltext auch erst einmal finden. Desweiteren hat man dann in einer Datei sowohl Code der zur Übersetzungszeit ausgeführt wird, als auch welchen der zur Laufzeit des späteren Programms ausgeführt wird. Wenn man das getrennt macht, ist es leichter das auseinanderzuhalten. Und die Interaktion mit dem C-Präprozessor muss man auch nochmal klären. Zu welchem Zeitpunkt passiert was? Was passiert mit Präprozessoranweisungen, die vom Python-Code erzeugt werden? Wann werden die ausgewertet? Wenn der ein ``#define`` ausspuckt, ist dessen Wert dann ab dem Zeitpunkt in folgenden Python-Codeblöcken bekannt? Weisst Du wie einfach oder auch aufwending das jeweils zu implementieren ist? Diese Sachen musst Du Dokumentieren, das ist also etwas mehr Doku als nur die Syntax.
Ich habe kein sinnloses Beispiel gezeigt was man alles dämliches mit dem C-Präprozessor machen kann. Solche Sachen kommen in freier Wildbahn tatsächlich vor. Ich rate Dir nochmal Dich in Header-Dateien von Compilern und Bibliotheken umzusehen. Da gibt's haufenweise bedingte ``#define``\s und auch ``#undef``\s und auch Rechnungen habe ich schon öfter gesehen. Gerade im Embedded-Bereich, zum Beispiel um irgendwelche Grössen auszurechnen und anhand derer zu entscheiden in welche Speicherbank bestimmte Daten am Ende geladen werden sollen. Da wären wir wieder bei fehlender Vorstellungskraft Deinerseits.
Ich habe übrigens nie gesagt "Nein das geht nicht", sondern "das macht in meinen Augen keinen Sinn". Du bist es von der falschen Seite angegangen. Was Du da gemacht hast, sieht nach billigem Template-System aus. Du musst aber Deine Idee in einen C-Präprozessor integrieren, und dazu müsste man den halt mal schreiben. Das ist nicht unmöglich, macht aber Arbeit. Und der sollte besser standardkonform sein, denn sonst hast Du ein System, das nicht mehr alle Quellen übersetzen kann, die auf den C-Standard setzen. Damit wär's für die Tonne.
Und Du hast IMHO immer noch nicht den Vorteil gezeigt, den der ganze Aufwand am Ende bringen soll. Solange Du nicht ein überzeugendes, durchdachtes Beispiel zeigen kannst, statt dem hingeklatschten, überkomlizierten Beispiel mit dem absolut gruseligem eingebetteten Python-Quelltext, den Du uns da bisher zugemutet hast, wirst Du kaum jemanden überzeugen können. Wenn ich meine Vorstellungskraft bemühe und aus dem extrapoliere was da zu sehen ist, wünschte ich mir deutlich weniger Phanasie zu haben.
Wieso sollte aus dem Umstand, dass die Alarmglocken schrillen wenn man seine eigene Template-Engine, sein eigenes Buildsystem oder VCS schreiben will, unmittelbar daraus folgen, dass es diese Dinge nicht gibt!? Gerade *weil* es sie schon gibt, sollte man sich gut überlegen das Rad noch einmal zu erfinden.
Python-Code in C eingebettet ist nicht leichter nachzuvollziehen als das extern zu machen. Das Syntax-Highlighting stimmt nicht, oder immer nur für eine der Sprachen. Und man muss den Python-Quelltext im C-Quelltext auch erst einmal finden. Desweiteren hat man dann in einer Datei sowohl Code der zur Übersetzungszeit ausgeführt wird, als auch welchen der zur Laufzeit des späteren Programms ausgeführt wird. Wenn man das getrennt macht, ist es leichter das auseinanderzuhalten. Und die Interaktion mit dem C-Präprozessor muss man auch nochmal klären. Zu welchem Zeitpunkt passiert was? Was passiert mit Präprozessoranweisungen, die vom Python-Code erzeugt werden? Wann werden die ausgewertet? Wenn der ein ``#define`` ausspuckt, ist dessen Wert dann ab dem Zeitpunkt in folgenden Python-Codeblöcken bekannt? Weisst Du wie einfach oder auch aufwending das jeweils zu implementieren ist? Diese Sachen musst Du Dokumentieren, das ist also etwas mehr Doku als nur die Syntax.
Ich habe kein sinnloses Beispiel gezeigt was man alles dämliches mit dem C-Präprozessor machen kann. Solche Sachen kommen in freier Wildbahn tatsächlich vor. Ich rate Dir nochmal Dich in Header-Dateien von Compilern und Bibliotheken umzusehen. Da gibt's haufenweise bedingte ``#define``\s und auch ``#undef``\s und auch Rechnungen habe ich schon öfter gesehen. Gerade im Embedded-Bereich, zum Beispiel um irgendwelche Grössen auszurechnen und anhand derer zu entscheiden in welche Speicherbank bestimmte Daten am Ende geladen werden sollen. Da wären wir wieder bei fehlender Vorstellungskraft Deinerseits.
Ich habe übrigens nie gesagt "Nein das geht nicht", sondern "das macht in meinen Augen keinen Sinn". Du bist es von der falschen Seite angegangen. Was Du da gemacht hast, sieht nach billigem Template-System aus. Du musst aber Deine Idee in einen C-Präprozessor integrieren, und dazu müsste man den halt mal schreiben. Das ist nicht unmöglich, macht aber Arbeit. Und der sollte besser standardkonform sein, denn sonst hast Du ein System, das nicht mehr alle Quellen übersetzen kann, die auf den C-Standard setzen. Damit wär's für die Tonne.
Und Du hast IMHO immer noch nicht den Vorteil gezeigt, den der ganze Aufwand am Ende bringen soll. Solange Du nicht ein überzeugendes, durchdachtes Beispiel zeigen kannst, statt dem hingeklatschten, überkomlizierten Beispiel mit dem absolut gruseligem eingebetteten Python-Quelltext, den Du uns da bisher zugemutet hast, wirst Du kaum jemanden überzeugen können. Wenn ich meine Vorstellungskraft bemühe und aus dem extrapoliere was da zu sehen ist, wünschte ich mir deutlich weniger Phanasie zu haben.
Ich finde ja, jeder sollte das "Recht" haben, jedes Stück Software bauen zu dürfen, egal ob es das schon X-mal gibt oder nicht. Somit wäre es doch eine nette "Fingerübung", einen syntaktisch zu cpp kompatiblen Präprozessor zu in Python zu bauen. Ebenso könnte man natürlich eine der 10+ Template-Sprachen aus der Python-Web-Entwicklung benutzen. Oder dies hier: http://ray.cg.tuwien.ac.at/rft/Papers/PYM/pym.html oder mal hier rauf gucken: http://pyparsing.wikispaces.com/message ... me/2706592
Der Quelltext auf github scheint mir noch Optimierungspotential zu haben. Auch kann er noch nicht die bekannten C-Präprozessoranweisungen umsetzen. Die halte ich für aufwendiger als jetzt noch eine weitere Anweisung für das Ausführen von Python-Code mittels eval() einzubauen. Der Tipp, einfach mal zu versuchen, die normalen (Linux) C-Header-Dateien erfolgreich zu parsen scheint mir ein guter Tipp und Testfall zu sein.
Stefan
Der Quelltext auf github scheint mir noch Optimierungspotential zu haben. Auch kann er noch nicht die bekannten C-Präprozessoranweisungen umsetzen. Die halte ich für aufwendiger als jetzt noch eine weitere Anweisung für das Ausführen von Python-Code mittels eval() einzubauen. Der Tipp, einfach mal zu versuchen, die normalen (Linux) C-Header-Dateien erfolgreich zu parsen scheint mir ein guter Tipp und Testfall zu sein.
Stefan
-
BlackJack
@sma: Das Recht will ich niemandem absprechen. Wenn die Ausgangslage gewesen wäre, dass jemand einen erweiterbaren C-Präprozessor als Fingerübung schreiben möchte, wäre meine Reaktion auch anders gewesen.
Bei dem PyParsing-Link steht zwar “Ich brauche einen C-Präprozessor” in der Betreffzeile der Beiträge, aber das entwickelt sich ja eher zu einem C-Parser. Von den Strukturen von C hat der C-Präprozessor keine Ahnung, der ist da doch etwas einfacher gestrickt also wohl einfacher umzusetzen.
Für's Testen einer eigenen Implementierung eines C-Präprozessors könnte man bei OpenSource C-Compilern nach Testfällen schauen.
Bei dem PyParsing-Link steht zwar “Ich brauche einen C-Präprozessor” in der Betreffzeile der Beiträge, aber das entwickelt sich ja eher zu einem C-Parser. Von den Strukturen von C hat der C-Präprozessor keine Ahnung, der ist da doch etwas einfacher gestrickt also wohl einfacher umzusetzen.
Für's Testen einer eigenen Implementierung eines C-Präprozessors könnte man bei OpenSource C-Compilern nach Testfällen schauen.
Ok... sry, das läuft hier glaub ich in die falsche Richtung.. war die letzte Woche auch leider recht unter Druck... also tut mir leid wenn ich ein bisschen harsch war...
Okay, wo soll ich anfangen? Also mal das mit dem Syntax hervorheben... tschuldige aber das ist ein schlechtes argument, muss man halt anpassen, bei vielen editoren ist das sicherlich möglich.. es geht ja auch für php...
Ein Konfigfile das den GESAMTEN Quellcode erstellt ist ja wohl sicher keine gute Lösung... sicher wenn ich nur ein zwei defines berechnen will, dann geht das, aber was ist wenns komplizierter wird?? Dann müsst ich da ein kompliziertes python skript erstellen, dass genauso gemischt ist wenn du willst, wie meines, nur dass du hier den quellcode wirklich nichtmehr erkennen kannst... du müsstest ja quasi dauernd textausgaben machen... so wie das bei php und html ist, hat das schon sinn...
Ihr habt natürlich vollkomment Recht! Die Source codes sind im wesentlichen pfusch. Im Prinzip ein einfacher text-sucher der eval benutzt nicht aufregend... und was ich im wesentlichen suche, wäre ne Methode mit ebensowenig aufwand die am besten den C Preprozessor nutzt und trickreich mit möglichst geringen einschränkungen dafür sorgt dass man in irgendeiner form in python die defines benutzen kann... mir ist klar dass sich das sehr unsauber anhört, um details kann ich mich ja kümmern wenn ichs soweit hab... ich dachte nur vielleicht hat jemand eine idee... ein anderer ansatz wäre die codes für z.b. den gnu c compiler und dem enthaltenen preprocessor herzunehmen, und das lustige python eval zeug da hinzuzufügen (gnu c ist ja hoffentlich in C oder C++ geschrieben, also lässt sich ja im prinzip gut integrieren) ... nur wäre dass dann halt ein eigener kompiler.. nicht so leicht zu verteilen... generell schwierig...
Wenn da nur ein python filter wäre, kann ich das einfach mitverteilen mit meinem makefile von irgendwelchen programmen...
ursprüunglich wollt ich ja zuerst nur das was es eh schon kann... sogar weniger... einfach einen ersatz für die methode ein python skript erstellt mir eine konfiguration... vielleicht wird es auch einfach nur das, wenn ich seh dass sich die neue idee nicht machen lässt... (insofern stimmt es natürlich dass ich mir noch nicht alles im detail überlegt hab... ich suche eben gerade nach einer möglichst unaufwendigen lösung)
Im Prinzip habt ihr auch mit eurem immer wieder erwähnten template system recht... ich könnte mir einfach eins aussuchen... quasi meine eigene erweiterungssprache bauen, bzw ist ja scheinbar auch schon einiges vordefiniert... und glücklich sein... nur würd ich halt lieber python als diese sprache sehen... (das war ja auch mit der grund warum ich das hier gepostet hab, sonst hätte das ja garnix mit python zu tun...)
ich würde gerne die ultimative lösung hinbekommen, geht das aber so garnicht, wird es warscheinlich einfach sowas wie php für html... und ich lass es quasi vom makefile in 2 schritten übersetzten... also im prinzip das gleiche wie ein config skript, nur anstatt print "#define VALUE %s" % "irgendwas" steht halt bei mir nur #define VALUE <?py:echo(wertdervorherberechnetwurde)?>... das sieht jetzt nicht soviel besser aus, aber was wenn ich da noch 10 normale defines hab... sicher ich könnt ein extra headerfile annlegen und dort alles fixe reintun, aber was wenn die sache verstrickter ist... ich glaub es ist im gewissen bereichen auch geschmackssache... ich persöhnlich finde das php konzept in dem bereich sehr klug...
Also gebt mir noch ein bisschen Zeit, ich bin noch nicht zu viel mehr gekommen als ein bisschen mit dem gcc rumzuspielen...
Die Idee die ich versuche umzusetzten geht mal in Richtung den zugriff durch #ifdefs zu ersetzten... im ersten schritt will ich mal nur quasi #ifdef und so unterstützen... danach geht es um konkrete werte...
Wie gesagt, versuchen tu ich mal so wenig wie möglich sebst machen zu müssen, indem ich einfach mal den preprozessor vom gcc arbeiten lasse... sollte dies so garnicht wollen, bericht ich euch wies weitergehen wird... wenn wer von euch noch einen voorschlag hat, was man noch probieren könnte um das zu erreichen, ist er natürlich herzlich eingeladen mir einen tipp zu geben...
Okay, wo soll ich anfangen? Also mal das mit dem Syntax hervorheben... tschuldige aber das ist ein schlechtes argument, muss man halt anpassen, bei vielen editoren ist das sicherlich möglich.. es geht ja auch für php...
Ein Konfigfile das den GESAMTEN Quellcode erstellt ist ja wohl sicher keine gute Lösung... sicher wenn ich nur ein zwei defines berechnen will, dann geht das, aber was ist wenns komplizierter wird?? Dann müsst ich da ein kompliziertes python skript erstellen, dass genauso gemischt ist wenn du willst, wie meines, nur dass du hier den quellcode wirklich nichtmehr erkennen kannst... du müsstest ja quasi dauernd textausgaben machen... so wie das bei php und html ist, hat das schon sinn...
Ihr habt natürlich vollkomment Recht! Die Source codes sind im wesentlichen pfusch. Im Prinzip ein einfacher text-sucher der eval benutzt nicht aufregend... und was ich im wesentlichen suche, wäre ne Methode mit ebensowenig aufwand die am besten den C Preprozessor nutzt und trickreich mit möglichst geringen einschränkungen dafür sorgt dass man in irgendeiner form in python die defines benutzen kann... mir ist klar dass sich das sehr unsauber anhört, um details kann ich mich ja kümmern wenn ichs soweit hab... ich dachte nur vielleicht hat jemand eine idee... ein anderer ansatz wäre die codes für z.b. den gnu c compiler und dem enthaltenen preprocessor herzunehmen, und das lustige python eval zeug da hinzuzufügen (gnu c ist ja hoffentlich in C oder C++ geschrieben, also lässt sich ja im prinzip gut integrieren) ... nur wäre dass dann halt ein eigener kompiler.. nicht so leicht zu verteilen... generell schwierig...
Wenn da nur ein python filter wäre, kann ich das einfach mitverteilen mit meinem makefile von irgendwelchen programmen...
ursprüunglich wollt ich ja zuerst nur das was es eh schon kann... sogar weniger... einfach einen ersatz für die methode ein python skript erstellt mir eine konfiguration... vielleicht wird es auch einfach nur das, wenn ich seh dass sich die neue idee nicht machen lässt... (insofern stimmt es natürlich dass ich mir noch nicht alles im detail überlegt hab... ich suche eben gerade nach einer möglichst unaufwendigen lösung)
Im Prinzip habt ihr auch mit eurem immer wieder erwähnten template system recht... ich könnte mir einfach eins aussuchen... quasi meine eigene erweiterungssprache bauen, bzw ist ja scheinbar auch schon einiges vordefiniert... und glücklich sein... nur würd ich halt lieber python als diese sprache sehen... (das war ja auch mit der grund warum ich das hier gepostet hab, sonst hätte das ja garnix mit python zu tun...)
ich würde gerne die ultimative lösung hinbekommen, geht das aber so garnicht, wird es warscheinlich einfach sowas wie php für html... und ich lass es quasi vom makefile in 2 schritten übersetzten... also im prinzip das gleiche wie ein config skript, nur anstatt print "#define VALUE %s" % "irgendwas" steht halt bei mir nur #define VALUE <?py:echo(wertdervorherberechnetwurde)?>... das sieht jetzt nicht soviel besser aus, aber was wenn ich da noch 10 normale defines hab... sicher ich könnt ein extra headerfile annlegen und dort alles fixe reintun, aber was wenn die sache verstrickter ist... ich glaub es ist im gewissen bereichen auch geschmackssache... ich persöhnlich finde das php konzept in dem bereich sehr klug...
Also gebt mir noch ein bisschen Zeit, ich bin noch nicht zu viel mehr gekommen als ein bisschen mit dem gcc rumzuspielen...
Die Idee die ich versuche umzusetzten geht mal in Richtung den zugriff durch #ifdefs zu ersetzten... im ersten schritt will ich mal nur quasi #ifdef und so unterstützen... danach geht es um konkrete werte...
Wie gesagt, versuchen tu ich mal so wenig wie möglich sebst machen zu müssen, indem ich einfach mal den preprozessor vom gcc arbeiten lasse... sollte dies so garnicht wollen, bericht ich euch wies weitergehen wird... wenn wer von euch noch einen voorschlag hat, was man noch probieren könnte um das zu erreichen, ist er natürlich herzlich eingeladen mir einen tipp zu geben...
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ja, ist ja ok. Jeder hat mal nen schlechten Tag.Manuelh87 hat geschrieben:Ok... sry, das läuft hier glaub ich in die falsche Richtung.. war die letzte Woche auch leider recht unter Druck... also tut mir leid wenn ich ein bisschen harsch war...
Naja, der Punkt ist dass das in PHP üblich ist, also PHP-Editoren sowohl PHP als auch HTML hervorheben. Genauso wie bei C und dem C-Präprozessor. Wohingegen das gleichzeigige Highlighten von zwei verschiedenen Sprachen in einer Datei nicht so üblich ist - vim kann das etwa gar nicht und Emacs MuMaMo ist auch eher als Hack zu sehen.Manuelh87 hat geschrieben:Okay, wo soll ich anfangen? Also mal das mit dem Syntax hervorheben... tschuldige aber das ist ein schlechtes argument, muss man halt anpassen, bei vielen editoren ist das sicherlich möglich.. es geht ja auch für php...
Inwiefern? Ich könnte mir folgendes vorstellen, um C-Code zu konfigurieren:Manuelh87 hat geschrieben:Ein Konfigfile das den GESAMTEN Quellcode erstellt ist ja wohl sicher keine gute Lösung... sicher wenn ich nur ein zwei defines berechnen will, dann geht das, aber was ist wenns komplizierter wird?? Dann müsst ich da ein kompliziertes python skript erstellen, dass genauso gemischt ist wenn du willst, wie meines, nur dass du hier den quellcode wirklich nichtmehr erkennen kannst... du müsstest ja quasi dauernd textausgaben machen... so wie das bei php und html ist, hat das schon sinn...
Code: Alles auswählen
import cdefines
config = cdefines.Config()
config.define('UART_BUFFER', 128 if cdefines.options.ASCII7 else 256)
config.write('config.h')Code: Alles auswählen
python config.py -DASCII7Was gefällt dir denn an diesem Ansatz nicht? Welche Anforderung die du hast, kann man damit nicht erfüllen?
Schon lustig, denn selbst moderne Frameworks in PHP wie CakePHP oder Symphony gehen eher weg von der Idee, PHP-Code in HTML zu mischen. Aber das nur so nebenbei.Manuelh87 hat geschrieben:ich persöhnlich finde das php konzept in dem bereich sehr klug...
@sma: Ich sehe hier auch niemandem, der Manuelh87 das Recht absprechen will, einen Präprozessor zu schreiben. Nur Leute die zu anderen Lösungen raten, die womöglich besser sind. Vielleicht sind wir ja schon zu sehr gewöhnt XY-Probleme zu lösen, als dass wir einfach eine Frage X ohne nachzuhaken beantworten können
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Yep. Wobei man mit LLVM ja auf Wunder hoffen kann...HerrHagen hat geschrieben:Für längst nicht jeden Prozessor gibt es einen Compiler für C++. Geschweige denn Compiler für andere Sprachen. Insofern halte ich die Idee gar nicht für so dumm.
http://llvm.org/
Hm... okay..
Also ich bin mittlerweile abgekommen von meiner ursprünglichen idee da ich eigentlich nach etwas ganz anderem gesucht habe... die idee hat sich dann entwickelt, aber leider in die falsche richtung...
Das eigentlich Problem war ja dass ich configurierbaren source code haben will, und das möglichst elegant aber auch leicht für andere verständlich... Da hilft es mir garnicht wenn dann mein preprocessor genauso übersetztungseinheit für übersetztungseinheit durchgeht... ich wollt eigentlich was globales...
So hier die Idee (und ich fürchte ihr werdet nicht begeistert sein...):
Ein kleines Buildsystem... ja ich hör schon wie die leute ihre köpfe gegen die wände schlagen...
Okay... also es soll so funktionieren: es gibt ein hauptverzeichnis, jedes irgendwie eigenständige modul ist in einem unterverzeichnis (die können wiederrum unterverzeichnisse haben)... module können ihre untermodule konfigurieren (das ist in den codes aber noch nicht drinn...). Es wird für jedes modul ein build-skript angelegt wo der programmierer des modules mit vordefinierten funktionen (gibts auch bis jetzt nur eine methode) [soll aber mal ne auswahl geben usw...] den user quasi nach der config abfragt. Die config wird gespeichert (in moment als pickle... soll aber mal les und schreibbar werden)... man muss also nicht jedes mal eingeben z.b. welche baudrate man haben will... außerdem sollen übergeordnete module die configuration der untermodule überschreiben können. Sichtbar sind in moment alle configurationen aller untermodule und des aktuellen modules...
Ansehen kann man sich das hier: git://github.com/boon-code/boyng.git die test branch soll (leider nicht sehr toll) zeigen was man vielleicht machen kann damit. Spätestens wenn ich einige der oben beschriebenen methoden implementiert hab, fang ich aber mit nem kleinen rfm12 treiber für atmegas an, da sieht man dann hoffentlich wozu das alles gut sein soll...
Aja es wird auch mal die möglichkeit geben die fragen quasi auf ein paar nett generierten tk oberflächen anzuklickseln... soll besonders einfach für neulinge sein, die z.b. meinen lustigen rfm treiber mal verwenden wollen...
Das ganze wird auch umgestellt auf cmake und so wie bei makefiles eigentlich auch üblich recursive abgearbeitet werden... also für jedes modul eine makefile (oder Makelist oder wie das heißt...)
Dazu muss ich mir aber nochmal cmake im detail ansehen...
Die Inline python code idee ist natürlich nicht verloren gegangen, aber es ist auch möglich diese globalen configurationen direkt per -D zu verwenden...
Klingt das ganz furchtbar? Bitte nicht den code bewerten, ich weiß dass das ein durcheinander ist... ich wollte zuerst unbedingt dass alles in einem file ist, aber mittlerweile seh ich auch dass das einfach nicht geht... das ganze ist quasi heute entstanden bis auf die paar zeilen von pyprep... dementsprechend sieht das halt noch aus... aber das wird verhübscht...
Also ich bin mittlerweile abgekommen von meiner ursprünglichen idee da ich eigentlich nach etwas ganz anderem gesucht habe... die idee hat sich dann entwickelt, aber leider in die falsche richtung...
Das eigentlich Problem war ja dass ich configurierbaren source code haben will, und das möglichst elegant aber auch leicht für andere verständlich... Da hilft es mir garnicht wenn dann mein preprocessor genauso übersetztungseinheit für übersetztungseinheit durchgeht... ich wollt eigentlich was globales...
So hier die Idee (und ich fürchte ihr werdet nicht begeistert sein...):
Ein kleines Buildsystem... ja ich hör schon wie die leute ihre köpfe gegen die wände schlagen...
Okay... also es soll so funktionieren: es gibt ein hauptverzeichnis, jedes irgendwie eigenständige modul ist in einem unterverzeichnis (die können wiederrum unterverzeichnisse haben)... module können ihre untermodule konfigurieren (das ist in den codes aber noch nicht drinn...). Es wird für jedes modul ein build-skript angelegt wo der programmierer des modules mit vordefinierten funktionen (gibts auch bis jetzt nur eine methode) [soll aber mal ne auswahl geben usw...] den user quasi nach der config abfragt. Die config wird gespeichert (in moment als pickle... soll aber mal les und schreibbar werden)... man muss also nicht jedes mal eingeben z.b. welche baudrate man haben will... außerdem sollen übergeordnete module die configuration der untermodule überschreiben können. Sichtbar sind in moment alle configurationen aller untermodule und des aktuellen modules...
Ansehen kann man sich das hier: git://github.com/boon-code/boyng.git die test branch soll (leider nicht sehr toll) zeigen was man vielleicht machen kann damit. Spätestens wenn ich einige der oben beschriebenen methoden implementiert hab, fang ich aber mit nem kleinen rfm12 treiber für atmegas an, da sieht man dann hoffentlich wozu das alles gut sein soll...
Aja es wird auch mal die möglichkeit geben die fragen quasi auf ein paar nett generierten tk oberflächen anzuklickseln... soll besonders einfach für neulinge sein, die z.b. meinen lustigen rfm treiber mal verwenden wollen...
Das ganze wird auch umgestellt auf cmake und so wie bei makefiles eigentlich auch üblich recursive abgearbeitet werden... also für jedes modul eine makefile (oder Makelist oder wie das heißt...)
Dazu muss ich mir aber nochmal cmake im detail ansehen...
Die Inline python code idee ist natürlich nicht verloren gegangen, aber es ist auch möglich diese globalen configurationen direkt per -D zu verwenden...
Klingt das ganz furchtbar? Bitte nicht den code bewerten, ich weiß dass das ein durcheinander ist... ich wollte zuerst unbedingt dass alles in einem file ist, aber mittlerweile seh ich auch dass das einfach nicht geht... das ganze ist quasi heute entstanden bis auf die paar zeilen von pyprep... dementsprechend sieht das halt noch aus... aber das wird verhübscht...
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Sorry, wenn ich wieder in die gleiche Kerbe haue wie viele meiner Vorredner, aber genau das ist doch die Aufgabe von Template Engines!Manuelh87 hat geschrieben: Das eigentlich Problem war ja dass ich configurierbaren source code haben will, und das möglichst elegant aber auch leicht für andere verständlich...
Das klassische Beispiel für diese sind ja idR. dynamische HTML-Seiten. HTML ist ja auch ein Quellcode und abhängig von Daten / Logik generiere ich mir mittels Template Engine dann eine individuelle Ausgabe. Ob ich nun HTML oder C oder sonst was als Zielformat habe, ist dabei ja komplett egal.
Mag sein, dass ich Dein Problem nicht genau verstanden habe, aber obiger Satz (und imho auch was danach folgt) ruft bei mir sofort diese Lösung in den Kopf.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Irgendwie erinnert mich das sehr an das Kernel-Build-System. hast du dir das mal angeschaut?Manuelh87 hat geschrieben:Aja es wird auch mal die möglichkeit geben die fragen quasi auf ein paar nett generierten tk oberflächen anzuklickseln... soll besonders einfach für neulinge sein, die z.b. meinen lustigen rfm treiber mal verwenden wollen...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
lunar
Das Kernel-Buildsystem ist ziemlich komplex, und für die Zwecke des OP viel zu viel. Die Anforderung "nette Konfigurations-GUI zum Kompilieren" würde ich persönlich eher mit CMake als Basis realisieren. Dessen Konfigurationsoberfläche dürfte einem einigermaßen fähigen Nutzer vollkommen ausreichen, und im Zweifelsfall kann man auch noch eine Tkinter-Oberfläche oben drauf setzen. Das programmatische Anpassen der CMake-Konfiguration ist auf jeden Fall viel einfacher als das Lesen und Verstehen von KBuild.
Ja, mein erster Weg war auch zu cmake, weil es so oft genannt wurde. Hatte auch zuerst das Gefühl dass ich damit genau mein Ziel realisieren könnte... aber irgendwie hats dan doch wieder nach vielem cmake-code ausgesehen... und bevor ich das ganze in so einer suboptimalen sprache machen muss, wollt ich lieber das ganze in python machen... Wichtig ist mir halt, dass man sich nicht durch etliche config files arbeiten muss, sondern einfach die config einmal auswählt... aus den picklen soll übrigens auch mal was lesbares werden, für die unter euch, die textuelles configurieren bevorzugen...
Was mir auch sehr wichtig war ist, dass man ohne großartiges Vorwissen und tonnen an doku schnell und einfach eigene module machen kann, die mit dem system konfiguriert werden... (ich hoffe das wird mir heute noch gelingen...) man soll nur python (meiner meinung nach ein must have
) und halt ein paar Methoden bzw. Objekte... kennen die ich dafür vorsehe...
Das ganze ist eigentlich eh fast die idee, einfach configure skripte zu machen... nur soll das ganze quasi standardisiert sein, und durch das makefile gesteuert.
Ich muss sagen ich hab leider nichts fertiges gefunden... Über das Kernel Build System bin ich auch gestolpert, war auch irgendwie (fällt mir jetzt rückwirkend auf) vielleicht an der Idee beteiligt... Aber hab mir gedacht dass das sicher viel zu kompliziert ist...
Ich weiß dass es noch früh ist, das zu beurteilen, aber meint ihr, dass es zumindest eine bessere Idee ist wie das was ich mir da zuvor ausgedacht hab? Es geht mir halt vor allem um Neulinge, die z.b. codes für den avr schnell verwenden wollen... ich weiß wie schwer ich mir getan hab, überhaupt mal alles zum laufen zu bringen. Außerdem kann man oft nur schwer fremde projekte ausprobieren, weil man schon an der anpassung scheitert... Mit einer grafischen Konfiguration, denke ich, kann ich vorallem Neulingen das Leben leichter machen...
Was mir auch sehr wichtig war ist, dass man ohne großartiges Vorwissen und tonnen an doku schnell und einfach eigene module machen kann, die mit dem system konfiguriert werden... (ich hoffe das wird mir heute noch gelingen...) man soll nur python (meiner meinung nach ein must have
) und halt ein paar Methoden bzw. Objekte... kennen die ich dafür vorsehe... Das ganze ist eigentlich eh fast die idee, einfach configure skripte zu machen... nur soll das ganze quasi standardisiert sein, und durch das makefile gesteuert.
Ich muss sagen ich hab leider nichts fertiges gefunden... Über das Kernel Build System bin ich auch gestolpert, war auch irgendwie (fällt mir jetzt rückwirkend auf) vielleicht an der Idee beteiligt... Aber hab mir gedacht dass das sicher viel zu kompliziert ist...
Ich weiß dass es noch früh ist, das zu beurteilen, aber meint ihr, dass es zumindest eine bessere Idee ist wie das was ich mir da zuvor ausgedacht hab? Es geht mir halt vor allem um Neulinge, die z.b. codes für den avr schnell verwenden wollen... ich weiß wie schwer ich mir getan hab, überhaupt mal alles zum laufen zu bringen. Außerdem kann man oft nur schwer fremde projekte ausprobieren, weil man schon an der anpassung scheitert... Mit einer grafischen Konfiguration, denke ich, kann ich vorallem Neulingen das Leben leichter machen...
-
lunar
Du möchtest also ein eigenes Buildsystem schreiben, weil Dir die graphischen Oberflächen der existierenden nicht gefallen haben? Die Idee ist wohl nur bedingt besser als Deine letzte ...
Ich möchte mich hier mal einklinken, weil mich das auch interessiert. Ich weiß in etwa, worauf er hinaus will.
Er hat ja das Beispiel mit dem UART (serielle Schnittstelle) genannt. Ich vermute, es geht dabei speziell um die AVR und den avr-gcc. Ich kenne das aus eigenen leidlichen Erfahrungen, wenn man für die UARTs der ATmega Controller eine gemeinsame Library schreiben will
Speziell das Beispiel mit der Berechnung der Baudrate kann ich nachvollziehen. In der avr-libc gibt es eine Header Datei, die aus der gewünschten Baudrate und dem CPU Takt die Registerwerte für den UART berechnet. Das ist aber ein elend umständliches Script und funktioniert auch nur für einen UART.
Der Grund dafür ist einfach, der Compiler soll zur Compilezeit aus den Eingangswerten die Registerwerte berechnen, damit der Programmierer das nicht jedes mal selber machen muss. Man könnte es auch in C implementieren, aber das wäre unnötige Speicherverschwendung.
Ein anderes Beispiel wären die unterschiedlichen Registernamen und teilweise unterschiedliche Registerbelegungen. Mit dem C Präprozessor muss man teilweise echte Klimmzüge machen und hat kilometerlange #defines und #ifdef's, um den Sourcecode an die unterschiedlichen Controller anzupassen.
Ich weiß nicht, ob eine Template Engine dafür geeignet ist und ich weiß auch nicht genau, was Manuelh87 noch alles vor hat. Aber an einer Lösung wäre ich auch interessiert.
Er hat ja das Beispiel mit dem UART (serielle Schnittstelle) genannt. Ich vermute, es geht dabei speziell um die AVR und den avr-gcc. Ich kenne das aus eigenen leidlichen Erfahrungen, wenn man für die UARTs der ATmega Controller eine gemeinsame Library schreiben will
Speziell das Beispiel mit der Berechnung der Baudrate kann ich nachvollziehen. In der avr-libc gibt es eine Header Datei, die aus der gewünschten Baudrate und dem CPU Takt die Registerwerte für den UART berechnet. Das ist aber ein elend umständliches Script und funktioniert auch nur für einen UART.
Der Grund dafür ist einfach, der Compiler soll zur Compilezeit aus den Eingangswerten die Registerwerte berechnen, damit der Programmierer das nicht jedes mal selber machen muss. Man könnte es auch in C implementieren, aber das wäre unnötige Speicherverschwendung.
Ein anderes Beispiel wären die unterschiedlichen Registernamen und teilweise unterschiedliche Registerbelegungen. Mit dem C Präprozessor muss man teilweise echte Klimmzüge machen und hat kilometerlange #defines und #ifdef's, um den Sourcecode an die unterschiedlichen Controller anzupassen.
Ich weiß nicht, ob eine Template Engine dafür geeignet ist und ich weiß auch nicht genau, was Manuelh87 noch alles vor hat. Aber an einer Lösung wäre ich auch interessiert.
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
Ach ja, die Parameter bekommt der Compiler üblicherweise mittels -D Parameter (für den CPU Takt) und -m (für den Mikrocontrollertyp) direkt übergeben. Damit das gesamte System noch wie vorher funktioniert (z.b. mit dem Eclipse Plugin oder mit vorhandenen Makefiles) dürfte es schwierig werden, einem externen Template System die Werte zu übergeben. Zumindest wüsste ich nicht wie
Es wäre jedenfalls sinnlos wenn man alles umkrempel müsste und einige Werkzeuge nicht mehr funktionieren
Es wäre jedenfalls sinnlos wenn man alles umkrempel müsste und einige Werkzeuge nicht mehr funktionieren
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
Verdammt ich seh grad cmake bietet so ein konfig ding an... das hab ich total übersehen....
Naja obwohl das jetzt nicht so optimal klingt, aber wenn ich das früher gesehen hätte.... naja
Ich wollt nur sagen das ganze lässt so auf sich warten weil ich von der idee das quasi alle unterordner untermodule darstellen die von dem modul darüber auch konfiguriert werden können etc. abgekommen bin...
Jetzt soll man das ganze in den configure skripts festlegen und zwar als kommentar... das ist eine art erweiterung und nicht unbedingt notwendig, aber man kann das module als input und als output angeben... input bedeutet man braucht die konfiguration von dem modul für die eigene, es soll also während dem ausführen des skripts verfügbar sein, output bedeutet man stellt gewisse parameter in dem angebenen modul ein...
Das mit dem Kommentar klingt sicher ganz böse, aber ich kann euch versichern, das war die sauberste Idee...
Leider wird es nun doch länger daueren bis wieder was halb-fertiges zu verfügung steht... aber ich stell den ganzen source code um...
@burli:
Ja exakt... diese avrs... das war genau der Beweggrund... und den eingebetteten python code will ich auch nur, weil ich damit viel einfacher und effizienter die Richtigen Prescaler Settings berechnen kann... ich glaube damit könnte man den #ifdef jungel ein bisschen verringern... außerdem könnte man zu jeder Option noch Hilfetext hinzufügen damit gerade neulinge eben wissen was sie da einstellen müssen... ich denk da immer an meine codes für die rfm12 chips... ich will die wirklich stark konfigurierbar machen, und vieles davon kann schon zur comile-zeit entschieden werden... und damit das ganze nutzbar für Einsteiger wird, soll das konfigurieren sehr leicht sein... am besten grafisch...
Nagut, ich halt euch auf dem Laufenden... werd mich gleich mal wieder dahinter klemmen...
Naja obwohl das jetzt nicht so optimal klingt, aber wenn ich das früher gesehen hätte.... naja
Ich wollt nur sagen das ganze lässt so auf sich warten weil ich von der idee das quasi alle unterordner untermodule darstellen die von dem modul darüber auch konfiguriert werden können etc. abgekommen bin...
Jetzt soll man das ganze in den configure skripts festlegen und zwar als kommentar... das ist eine art erweiterung und nicht unbedingt notwendig, aber man kann das module als input und als output angeben... input bedeutet man braucht die konfiguration von dem modul für die eigene, es soll also während dem ausführen des skripts verfügbar sein, output bedeutet man stellt gewisse parameter in dem angebenen modul ein...
Das mit dem Kommentar klingt sicher ganz böse, aber ich kann euch versichern, das war die sauberste Idee...
Leider wird es nun doch länger daueren bis wieder was halb-fertiges zu verfügung steht... aber ich stell den ganzen source code um...
@burli:
Ja exakt... diese avrs... das war genau der Beweggrund... und den eingebetteten python code will ich auch nur, weil ich damit viel einfacher und effizienter die Richtigen Prescaler Settings berechnen kann... ich glaube damit könnte man den #ifdef jungel ein bisschen verringern... außerdem könnte man zu jeder Option noch Hilfetext hinzufügen damit gerade neulinge eben wissen was sie da einstellen müssen... ich denk da immer an meine codes für die rfm12 chips... ich will die wirklich stark konfigurierbar machen, und vieles davon kann schon zur comile-zeit entschieden werden... und damit das ganze nutzbar für Einsteiger wird, soll das konfigurieren sehr leicht sein... am besten grafisch...
Nagut, ich halt euch auf dem Laufenden... werd mich gleich mal wieder dahinter klemmen...
Ein alternatives Build System, welches im übrigen Python verwendet, ist Scons. Ich habe das sogar schon verwendet
http://www.wiki.elektronik-projekt.de/m ... /scons_avr
Allerdings bin ich da noch nicht weiter gekommen
http://www.wiki.elektronik-projekt.de/m ... /scons_avr
Allerdings bin ich da noch nicht weiter gekommen
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
Ja das hab ich auch zuletzt begutachtet... wollt nochmal schaun ob es nicht doch irgendwas gibt wo man erweitern könnte... muss aber sagen dass es mir zu kompliziert klang... also wenn ich nach 10 Minuten Doku suchen und lesen, mir noch immer kein Bild machen kann, was das Ding alles kann...
Ich hab zwar gelesen dass es auch "configuration" unterstützt.... aber was das bedeutet... und in welcher form... für mich hat es eher ausgesehen wie ein weiteres make oder cmake oder so...
Mein lustiges Programmchen hier soll ja nur das Konfigurieren beherrschen... es wird eingebettet in make, oder cmake... in Moment make.
Bin jetzt mit dem neuen System zirka soweit wie ich davor war... gestern fertig gestellt... heute am Abend werd ichs mal testen und vielleicht schonmal die TextConfig Option anfangen.. also auf der console...
Gibts irgendwelche Python Module die für console geeignet sind und auf windows und unixoiden OS laufen? curses glaub ich eher nicht oder? Meine derzeitige Variante wäre einfach per raw_input fragen... also wo das möglich ist... bzw wenn der user auswählen muss dann nach na nummer fragen oder so... ihr versteht...
Aber ich fänds gut, wenn das ein bisschen bequemer Möglich wäre...
Ich hab zwar gelesen dass es auch "configuration" unterstützt.... aber was das bedeutet... und in welcher form... für mich hat es eher ausgesehen wie ein weiteres make oder cmake oder so...
Mein lustiges Programmchen hier soll ja nur das Konfigurieren beherrschen... es wird eingebettet in make, oder cmake... in Moment make.
Bin jetzt mit dem neuen System zirka soweit wie ich davor war... gestern fertig gestellt... heute am Abend werd ichs mal testen und vielleicht schonmal die TextConfig Option anfangen.. also auf der console...
Gibts irgendwelche Python Module die für console geeignet sind und auf windows und unixoiden OS laufen? curses glaub ich eher nicht oder? Meine derzeitige Variante wäre einfach per raw_input fragen... also wo das möglich ist... bzw wenn der user auswählen muss dann nach na nummer fragen oder so... ihr versteht...
Aber ich fänds gut, wenn das ein bisschen bequemer Möglich wäre...
Okay... es ist soweit. Die erste relativ ungetestete Version ist mal da: git://github.com/boon-code/buildsystem.git (der branch exp)
Bin grad dabei, ein kleines Modul für ein lcd zu schreiben, auch ein bisschen als Beispiel Source-Code...
Ein Problem ist, dass man dafür sorgen muss, dass möglicher python code und defines die vom build-system kommen auch in header files ersetzt werden... in moment ist meine Lösung, dass alle Header die Defines vom Buildsystem verwenden mit [xy].h.in heißen... bei Source-Dateien ist es kein Problem...
Das ganze ist leider ein wenig ausgeartet und die Source-Codes sind nicht das schönste... werd mich aber bemühen da zumindest doc-strings mal einzufügen (möglichst bevor ich selber vergessen hab was ich mir dabei gedacht hab)...
Falls jemand daran interessiert ist, kann ich gerne ein bisschen darauf eingehen, wie man es verwendet. Es sollte nicht zu schwer sein, und es ist fast alles erlaubt (in den configure-skripts) was man auch in normalem python darf... außerdem sollte es möglich sein, auf das inline python dings auch vollkommend zu verzichten (sofern man keine schleifen braucht) und nur mit dem configure-skript, und den defines zu arbeiten...
Wie gesagt, ein Beispiel kommt bald (ich denk nur mit dem source code, ohne fertiges makefile wird wohl kaum jemand was damit anfangen können). Und damit es nicht wieder ein mieses gekünsteltes wird, hab ich mir gedacht, nehm ich einfach ein echtes (kleines).
Bin grad dabei, ein kleines Modul für ein lcd zu schreiben, auch ein bisschen als Beispiel Source-Code...
Ein Problem ist, dass man dafür sorgen muss, dass möglicher python code und defines die vom build-system kommen auch in header files ersetzt werden... in moment ist meine Lösung, dass alle Header die Defines vom Buildsystem verwenden mit [xy].h.in heißen... bei Source-Dateien ist es kein Problem...
Das ganze ist leider ein wenig ausgeartet und die Source-Codes sind nicht das schönste... werd mich aber bemühen da zumindest doc-strings mal einzufügen (möglichst bevor ich selber vergessen hab was ich mir dabei gedacht hab)...
Falls jemand daran interessiert ist, kann ich gerne ein bisschen darauf eingehen, wie man es verwendet. Es sollte nicht zu schwer sein, und es ist fast alles erlaubt (in den configure-skripts) was man auch in normalem python darf... außerdem sollte es möglich sein, auf das inline python dings auch vollkommend zu verzichten (sofern man keine schleifen braucht) und nur mit dem configure-skript, und den defines zu arbeiten...
Wie gesagt, ein Beispiel kommt bald (ich denk nur mit dem source code, ohne fertiges makefile wird wohl kaum jemand was damit anfangen können). Und damit es nicht wieder ein mieses gekünsteltes wird, hab ich mir gedacht, nehm ich einfach ein echtes (kleines).