Es ist mal wieder so weit. Ich hab mir picklebuild (http://www.python-forum.de/viewtopic.php?f=6&t=22781) wieder eingebildet und programmier schon wieder einige Zeit drann herum.
Was das ganze überhaupt sein soll:
Picklebuild soll ein Konfigurationssystem werden (unter Umständen auch einmal die funktionalität von make haben, das ist aber fürs erste nicht wichtig). Die erste ganz fertige Version wird aber vermutlich in ein Makefile eingebettet, also muss sich nur um die Konfiguartion kümmern (das reicht eh schon). Auch wird vorerst nur C/C++ unterstützt werden. Gedacht hab ich beim entwickeln vorallem an Mikrokontroller Projekte wo man statische Konfiguartionen (zur Compilierzeit) einfach festlegen will. Ganz konkret hab ich da ein projekt von mir mit dem rfm12 (Funkchip/platine) und einem Atmega (der vermutlich aber bald durch einen Pic ersetzt wird). Da gibt es einige Parameter festzulegen die (zumindest ich) nicht vorhabe zur laufzeit zu ändern. Unter anderem soll es das Problem mit einer gleichen Source Basis für verschiedene Platinen (mit verschiedenen Ports an denen z.b. ein LCD oder eben das RFM hängt) lösen (man soll einfach die entsprechende konfigurationsdatei nehmen und kann immer den selben source code verwenden und diesen auch an einer stelle in einem source verwaltungs tool warten. Dadurch soll eine Flut an defines aller Möglichkeiten wo alle nicht verwendeten auskommentiert sind vermieden werden (Ja diese Dinge hab ich schon häufig gesehen). Auch komplizierte bash scripts wie sie oftmals in Makefiles eingebunden werden sollen vermieden werden.
Funktionieren soll das ganze so, dass man für eine abgeschlossene Einheit (ein C-modul) ein python script (mit kleinen sprachergänzungen) erstellt, dass die Variablen die man im source code braucht, festlegt. Das geht relativ einfach indem man eine die entsprechende funktion des 'cfg' objects (wird als globale variable von picklebuild bereitgestellt) aufruft und z.b. eine Liste von Möglichkeiten oder einen Text erstellt. Jede dieser variablen hat einen eindeutigen namen. Prinzipiell teilen sich nur ganze Module diese variablen (zu einem Modul gehören für picklebuild alle ausgewählten source dateien im verzeichniss wo ein configure_xxx.py [xxx ist der eindeutige Module name] script liegt und alle Unterordner [und Unterordner von Unterordnern, usw...] die kein configure_xxx.py script haben...). Allerdings ist es durch sogenannte Extension Befehle möglich, andere module in den Namensraum aufzunehmen, zu lesen, zu überschreiben etc...(funktioniert jedoch noch nicht einwandfrei, da muss noch nachgebessert werden). Entweder wird für jedes modul ein include file generiert, dass die entsprechenden defines enthält, oder sie werden direkt eingefügt, was mir aber nicht so gefällt. Das Konzept ist hier, dass der gesamte src-tree kopiert wird und dabei auch durch einen kleinen python preprocessor (picklebuild1) gejagt wird, der auch inline python code auswerten kann. Bevor das wieder zu Dikussionen führt: Es ist nicht notwendig Inline python code zu verwenden, lediglich möglich z.b. an Stellen, wo man mit include define und undefine anfangen würde so was ähnliches wie ne Schleife zu konstruieren etc... Es ist nur möglich! Aber gerade durch die neue Idee wie das configure script aufgebaut sein soll, sollte es möglich sein, fast alles, was in irgendeiner form Schleifen brauchen würde schon im script zu machen und damit den inline code nicht zu verwenden.
Derzeit funktionieren gerade einmal die Hauptteile (wobei überschreiben und lesen noch problematisch sein kann, da bin ich aber schon drann...). Das Script wird nämlich ausgeführt und die entsprechenden Objekte angelegt. Da Abhängigkeiten möglich sind (man will zuerst den PORT wo z.b. eine Led drannhängt eingegeben haben und dann erst nach dem pin fragen, etc.) ist das ganze nicht so einfach, was sich leider auch auf den code niederschlägt. Außerdem beinhaltet er unter Umständen falsche Kommentare. Ich wäre einfach nicht nachgekommen mit ausbessern, ich wollt zuerst dass das Grundsystem steht (Ich habs am Anfang so probiert, aber es ist mehr als ärgerlich wenn große Teile gelöscht werden die du gerade toll dokumentiert hast). Kleine Änderungen daran sind noch notwendig, dann wird das aber ausgebessert und aller Ballast abgeworfen.
Man kann bitte noch nichts damit konfigurieren, aber das sind Kleinigkeiten wo ich viel aus der ersten Version (die ja soweit funktioniert hat, aber unpraktisch war) übernehmen werde. Die jetztige Version beinhaltet eine mehr als rundimentäre gui und den Teil, der das configure_xxx.py script verarbeitet. Man kann sich also mit dem Teil spielen und schaun ob es funktioniert.
(den apply button in der gui bitte ignorieren, es wird automatisch gemacht [bei Text variablen leider nach jedem Zeichen; ich komm einfach mit tkinter nicht so ganz zurecht...])
So, das ganze befindet sich hier https://github.com/boon-code/picklebuild3/tree/simple (wichtig ist, dass ihr am branch 'simple' seit; in den Hauptzweig kommt das ganze erst, wenn die doku okay ist und ich das schon erwähnte problem mit override und Abhägnigkeiten von anderen modulen gelöst habe... kurz: wenn der Kern des ganzen einwandfrei funktioniert.).
Wenn jemand das ganze ausprobieren will (den im derzeitigen Zustand, will sich wohl kaum einer die sourcen durchlesen...) so kann man das so machen:
zuerst auschecken von der Github Seite... (siehe oben) (branch 'simple')
test-tree.tar.gz entpacken (cat test-tree.tar.gz|tar xz)
in den source Ordner wechseln (cd src/)
und den python3 interpreter starten (python3 test.py)
>> Nun sollte ein häßliches tkinter fenster erscheinen und man kann die aufgelisteten Module durchgehen (Es haben nur 2 davon nodes, die anderen sind leer).
Zu den Farben und dem Verhalten:
Wenn man etwas konfiguriert hat dann wird es grün.
Graue Einträge sind 'disabled' (man kann optionen abhängig von einer option ausschalten, das soll vorallem praktisch sein um z.b. ganze features ein und auszuschalten. Sind sie diese dann aus, machen viele Einträge oftmals mehr keinen sinn... z.b.: Fehlerkorrektur wird ausgeschaltet -> es ist nichtmehr wichtig welche art von korrektur man verwenden wollte (wenn z.b. mehrere implementiert wurden)
Nicht wundern wenn Einträge dazukommen und wegkommen, das liegt daran dass Abhängig von diesem einem Parameter, entweder die einen, oder die anderen optionen erstellt werden. Das wirkt vielleicht lässtig, aber mir ist leider keine bessere Möglichkeit eingefallen und es ist auch nicht ratsam, extrem komplizierte configure_xxx.py scripts zu schreiben. Aber es ist halt einiges möglich.... Außerdem wird stehts versucht, alte Werte wiederzuverwenden... Ein Beispiel: Ich hab code um buttons die an einen Kontroller angeschlossen wurden zu verwalten. Zuerst würde ich beim module script fragen, wieviele buttons man haben möchte, abhängig davon würde ich dann Pin und Port abfragen. Wenn man sich nun für 3 buttons entscheidet, die dann auftauchenden Variablen festlegt, und nun merkt dass man doch 4 buttons brauch, so werden (Obwohl die Objekte neu erstellt werden) die alten werde für button1, button2 und button3 verwendet, während nur button4 neu zu konfigurieren ist....
Nun zu meinem eigentlichen Anliegen: Hat jemand Lust und Zeit, das Projekt zu unterstützen. Also das ganze soll unter eine freie Lizenz (GPL oder dergleichen). Gehostet ist es ja sowieso schon auf github, da kann ich einfach Zugänge anlegen. Wirklich sinnvoll wird das ganze wohl erst, wenn ich die doku halbwegs hinbekommen hab und der Kern läuft. Ich frag trotzdem schon mal an, da es sicher ein wenig dauert bis der Beitrag gelesen wird und sich wohlmöglich doch jemand meldet. Würd mich sehr freuen, aber ich kann natürlich verstehen, wenn einen der momentane Code etwas abschreckt oder das Thema nicht interessiert. Es gäbe auf jeden Fall auch Dinge zu tun die es nicht erfordern den ganzen Kern durchzugehen z.b. die gui überarbeiten, später entsprechenden module für andere Programmiersprachen, XML Konfigurations Dateien (da hab ich schon codeteile, falls sich jemand da reinarbeiten will), Kommandozeilen parameter verarbeiten, vielleicht ein optionales interface in qt, eines für die Konsole?!
Es geht nicht nur darum, dass das Projekt schön langsam schwierig für mich alleine zu bewältigen ist, sondern vorallem um das miteinander programmieren und voneinander lernen. Ein Stückweit geht's mir natürlich auch darum, einmal so ein Projekt zu starten, dass von mehr als 1 Person entwickelt wird und vielleicht von nochmehr Menschen genutzt wird.
Bitte seit nicht zu streng mit mir, wie schon erwähnt ist der Code in Moment schlampig und viele Fehler werden nicht abgefangen. Ich kann leider immer nur ein Problem nach dem anderen beheben und es war mir einfach wichtiger, dass einmal das Kern system steht (zumindest für eine erste Demonstration). Das ganze stürzt beim geringsten Fehler in der config datei noch gnadenlos ab und unter Umständen sogar bei korrektem Gebrauch (um das auszuschließen hab ich es leider erst zu wenig getestet). Das sind aber alles Dinge die sich relativ leicht beheben lassen sollten, aber wie schon erwähnt, eines nach dem anderen. Ansonsten bin ich für jede Kritik und Verbesserungsvorschläge offen und freu mich schon auf Feedback.
Ich bedanke mich schon jetzt mal bei denen, die es bis hier her gelesen haben
cu Manuel
