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...
python preprocessor für C/C++
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).
Ich verbessere den Link mal: http://github.com/boon-code/buildsystem 
Hi!
Das freut mich... aber es hat leider noch recht schlimme Mängel... Ich hab auch zur Zeit wenig Möglichkeit viel daran zu ändern, vor allem fehlt mir ein gutes Konzept...
Jedes mal wenn ich config skripts dafür schreib, fällt mir auf, was alles noch schlecht ist... aber wenn ich Zeit hab, werd ich das hoffentlich verbessern können.
Komplizierte Dinge kann man noch nicht wirklich gut machen...
Doku gibts noch keine, aber ich hab hier mal ein kleines Beispiel... http://github.com/boon-code/tlcd-ks0066
Ist nicht besonders aufregend, aber es checkt automatisch z.b. eingegebene Zahlen ob sie in einem bestimmten Bereich sind, und es fragt z.b. nach dem PORT auf dem man (ein text lcd) angeschlossen hat und leitet darauß die PIN und DDR Register ab (ATmega).
Wahrscheinlich wird das ganze aber nochmal redesigned... ich würde auch gerne etwas anbieten wo man ein bisschen die portabilität erhöht... eine art list wo man die hardware des verwendeten chips auflisten kann und die einzelnen Module z.b. sich ausmachen können, welchen Timer wer verwendet... (nagut das ist ne zukunftsvision)...
Also einfache Dinge funktionieren schon (wurde aber bitte nur auf linux getestet, k.a. wie man das alles auf windows einrichten könnte... damit muss ich mich aber früher oder später auch befassen...) und es funktioniert alles über makefiles... Header files die auf die defines zugreifen wollen müssen in der HEADER liste eingetragen werden (userconfig.mk) und mit .h.in enden...
Das ist leider noch so, soll aber mal geändert werden...(ist so einfacher weil ich die defines einfach auswerten kann und als .h abspeichern, dass dann normal included wird...).
Komplizierte Dinge enden meist in extrem langen komplizierten config files und funktioniern dann am Ende doch nicht so wie sie sollen...
Wie gesagt, ich denke mal wieder über ein redesign nach. Mir wird halt auch erst beim Anwenden klar, wie mans besser machen könnte... wird aber ein bisschen dauern...
Tk Oberfläche gibts auch noch keine... aber das will ich gleich zusammen mit den nächsten Änderungen erledigen. Dann soll es nurmehr die Tk Oberfläche geben... das Konsolen ding von mir ist eh mehr schlecht als recht...
Es wird also noch dauern bis man es wirklich gut einsetzten kann
Das freut mich... aber es hat leider noch recht schlimme Mängel... Ich hab auch zur Zeit wenig Möglichkeit viel daran zu ändern, vor allem fehlt mir ein gutes Konzept...
Jedes mal wenn ich config skripts dafür schreib, fällt mir auf, was alles noch schlecht ist... aber wenn ich Zeit hab, werd ich das hoffentlich verbessern können.
Komplizierte Dinge kann man noch nicht wirklich gut machen...
Doku gibts noch keine, aber ich hab hier mal ein kleines Beispiel... http://github.com/boon-code/tlcd-ks0066
Ist nicht besonders aufregend, aber es checkt automatisch z.b. eingegebene Zahlen ob sie in einem bestimmten Bereich sind, und es fragt z.b. nach dem PORT auf dem man (ein text lcd) angeschlossen hat und leitet darauß die PIN und DDR Register ab (ATmega).
Wahrscheinlich wird das ganze aber nochmal redesigned... ich würde auch gerne etwas anbieten wo man ein bisschen die portabilität erhöht... eine art list wo man die hardware des verwendeten chips auflisten kann und die einzelnen Module z.b. sich ausmachen können, welchen Timer wer verwendet... (nagut das ist ne zukunftsvision)...
Also einfache Dinge funktionieren schon (wurde aber bitte nur auf linux getestet, k.a. wie man das alles auf windows einrichten könnte... damit muss ich mich aber früher oder später auch befassen...) und es funktioniert alles über makefiles... Header files die auf die defines zugreifen wollen müssen in der HEADER liste eingetragen werden (userconfig.mk) und mit .h.in enden...
Das ist leider noch so, soll aber mal geändert werden...(ist so einfacher weil ich die defines einfach auswerten kann und als .h abspeichern, dass dann normal included wird...).
Komplizierte Dinge enden meist in extrem langen komplizierten config files und funktioniern dann am Ende doch nicht so wie sie sollen...
Wie gesagt, ich denke mal wieder über ein redesign nach. Mir wird halt auch erst beim Anwenden klar, wie mans besser machen könnte... wird aber ein bisschen dauern...
Tk Oberfläche gibts auch noch keine... aber das will ich gleich zusammen mit den nächsten Änderungen erledigen. Dann soll es nurmehr die Tk Oberfläche geben... das Konsolen ding von mir ist eh mehr schlecht als recht...
Es wird also noch dauern bis man es wirklich gut einsetzten kann
Ich bastle immer noch an einer Lösung mit Quickly. Das hat derzeit nur noch zwei Nachteile. Zum einen gibt es Quickly derzeit nur für Ubuntu, weil es von Canonical entwickelt wird und es ist noch in der Entwicklung.
Quickly hat so gesehen auch nichts mit den Libraries zu tun sondern ist eher eine Projektverwaltung auf Konsolenebene. Da man die Befehle für die Projekte selbst schreiben kann/muss kann man da aber auch problemlos Funktionen für das Patchen der Libs einbauen. Und da bin ich gerade dabei festzustellen, wie man das am besten lösen kann
Quickly hat so gesehen auch nichts mit den Libraries zu tun sondern ist eher eine Projektverwaltung auf Konsolenebene. Da man die Befehle für die Projekte selbst schreiben kann/muss kann man da aber auch problemlos Funktionen für das Patchen der Libs einbauen. Und da bin ich gerade dabei festzustellen, wie man das am besten lösen kann
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol: