Hallo zusammen,
Ich habe bislang noch keine Erfahrung mit Python, doch denke ich dass sich die Sprache zur Lösung des folgenden Problems eignet:
Ein C-Projekt besteht aus ca. 30 Dateien. In diesen kann mit Präprozessor Befehlen definiert werde kann, ob Funktionalitäten im Build untestützt werden sollen oder nicht. Mittlerweile ist der Source-Code aber nur noch schwer zu lesen. Es wäre daher ein grosser Vorteil, in Abhängigkeit der gewünschten Konfiguration, 'lesbare' Code Datien mittels eines Python-Skripts zu erzeugen.
Hat jemand von Euch einen Tipp, wie dies effizient in Python gemacht wird?
Spark
Parsing eines C-Projektes
-
BlackJack
Das würde ich ohne Python machen. Der C-Präprozessor kann bei den meisten Compilern auch einzeln aufgerufen werden.
Ja, sogenannte *.lst Files können erzeugt werden. Diese sind jedoch nicht einfacher zu lesen.
Der 'aufgeräumte' source code wird zudem in einem weiteren Compiler verwendet welcher die besagten Präprozessor Befehle nicht auswerten kann.
Ich möchte den source code so generieren, dass nur die Teile entalten sind welche von den Direktiven zugelassen werden.
Kann dies mit dem Python eigenen Parser Objekt gelöst werden?
Spark
Der 'aufgeräumte' source code wird zudem in einem weiteren Compiler verwendet welcher die besagten Präprozessor Befehle nicht auswerten kann.
Ich möchte den source code so generieren, dass nur die Teile entalten sind welche von den Direktiven zugelassen werden.
Kann dies mit dem Python eigenen Parser Objekt gelöst werden?
Spark
-
BlackJack
Nein der Python-Parser parst nur Python.
Wenn sich die Konfiguration nur auf einfache ``#define``\s und ``#ifdef``/``#ifndef``\s bezieht, dann sollte man recht einfach einen Parser/Präprozessor dafür schreiben können. Wenn auch ``#if``\s vorkommen, dann wird's schwieriger weil dort fast beliebige ganzzahlige konstante C-Ausdrücke stehen dürfen.
Präprozessor-Kontrollzeilen sind leicht zu erkennen. Wenn der "Inhalt" einer Definition nicht wichtig ist, dann kann man beide Definitionsarten (Konstante und Makro) gleich behandeln weil man nur den Bezeichner benötigt, der gleich nach dem Schlüsselwort ``#define`` folgt. Wenn man auf so eine Zeile trifft, dann muss man sich nur merken, dass es diesen Bezeichner jetzt gibt. Kann man in einem `set` speichern.
Bei ``#undef`` muss man den Bezeichner wieder löschen.
``#include`` muss man zumindest verarbeiten, da dort Makros/Konstanten definiert werden könnten.
Die bedingten Übersetzungen muss man rekursiv verarbeiten, da die Bedingungen ja verschachtelt sein dürfen.
Wenn sich die Konfiguration nur auf einfache ``#define``\s und ``#ifdef``/``#ifndef``\s bezieht, dann sollte man recht einfach einen Parser/Präprozessor dafür schreiben können. Wenn auch ``#if``\s vorkommen, dann wird's schwieriger weil dort fast beliebige ganzzahlige konstante C-Ausdrücke stehen dürfen.
Präprozessor-Kontrollzeilen sind leicht zu erkennen. Wenn der "Inhalt" einer Definition nicht wichtig ist, dann kann man beide Definitionsarten (Konstante und Makro) gleich behandeln weil man nur den Bezeichner benötigt, der gleich nach dem Schlüsselwort ``#define`` folgt. Wenn man auf so eine Zeile trifft, dann muss man sich nur merken, dass es diesen Bezeichner jetzt gibt. Kann man in einem `set` speichern.
Bei ``#undef`` muss man den Bezeichner wieder löschen.
``#include`` muss man zumindest verarbeiten, da dort Makros/Konstanten definiert werden könnten.
Die bedingten Übersetzungen muss man rekursiv verarbeiten, da die Bedingungen ja verschachtelt sein dürfen.