Nochmal eine kurze Anmerkung zu den Build-Systemen: Ich spiele derzeit ein bisschen mit waf rum. und obwohl es eigentlich ganz nett ist, ist es für Reflex vielleicht eher nicht geeignet. Jedenfalls gefällt mir dafür der qbs Ansatz besser. Und es scheint nun auch ein paar qbs Pakete für Debian zu geben [1]. Damit sind meine Einwände gegen qbs vom Tisch ;)
Grüße Stefan [1] https://ftp-master.debian.org/new/qbs_1.2.2+dfsg-1.html Am 26.07.2014 12:54, schrieb Richard Weickelt: > Hallo zusammen, > > ich habe mit einer Umstrukturierung des REFLEX-Repositories begonnen. > **Bestehende Applikationen bleiben ohne Codeanpassung lauffähig**. Nur das > Makefile muss angepasst werden. Die Änderungen kann man hier nachlesen: > > https://bitbucket.org/reflex-dev/reflex/commits/branch/feature%2Fcode-reorganization > > Zusammenfassung > --------------- > 1. Die alten Ordner "system" und "lib" werden langsfristig verschwinden und > der Code nach Funktion getrennt und in Pakete verschoben. Die alten > include-Pfade im Code behalten aber ihre Gültigkeit. D.h. ein #include > "reflex/io/XXX.h" funktioniert weiterhin. Es wird eine Aufgabe des > Buildsystems, dies aufzulösen. Folgende Pakete sind dabei bisher entstanden: > - buffer > - components > - core > - protothread > - virtualtimer > - xml > > Außerdem habe ich Quellcode und Header verschmolzen. Eine Trennung der > beiden ist unnötiger Pflegeaufwand. Eine Extraktion der Header und die > Installation in einen Includeordner sollte durch das Buildsystem abgedeckt > werden. > > 2. Es gibt keine äußerlich sichtbare Unterscheidung mehr zwischen Controller > und Plattform. Wie von Stefan Nürnberger vorgeschlagen, habe ich zum > Beispiel 'linux' und 'guest' zu 'posix' verschmolzen. 'atmega' wurde > ebenfalls angepasst. Weiterhin habe ich 'MSP430X' und 'EZ430-chronos'. Diese > Pakete liegen nun alle im Ordner 'platform'. Es ist möglich, mehrere > Plattformordner auszuwählen, so lange sie sich nicht überschneiden. D.h. > EZ430-chronos ist eine Ergänzung zu MSP430X. Es ist Aufgabe des Entwicklers, > die richtigen Plattformordner zu wählen und das Buildsystem sollte sich um > den Rest kümmern. Was mit dem MSP430 Controller (ohne x) passieren wird, ist > noch unklar. > > 3. Die Abhängigkeiten zwischen core, Plattform, zusätlichen Paketen und der > Applikation wurden entflechtet. Keine Datei in einem Paket darf irgendwelche > Header der Applikation laden. Beim Bauen darf core auf die Header von > Plattform zugreifen. Das geht nicht anders, denn die Plattform definiert > essentielle Datentypen. Nachdem 'core' gebaut wurde, kann das > Plattformbasispaket gebaut werden, bzw. alle plattformunabhängigen Pakete. > Applikationsabhängige Parameter müssen als defines beim Kompilieren des > Frameworks übergeben werden bzw. beim Bauen der Applikation. Es wird Aufgabe > des Buildsystems, diese defines bei den richtigen Headerdateien abzuliefern. > > Was damit allerdings bleibt, ist die Notwendigkeit, das Framework für jeden > Anwendungsfall neu zu kompilieren. Macht aber nichts, denn > > 4. Ein Vorschlag für ein neues Buildsystem wurde in einem separaten Zweig > hinzugefügt. > https://bitbucket.org/reflex-dev/reflex/commits/1306dccd47a9a4686a6e441716520d096d697c19?at=feature/build-with-qbs > Ungeachtet der (berechtigten) Kritik habe ich das Qt Build system (QBS) > gewählt. Es bietet Funktionen, die optimal zu unserem Einsatzzweck passen > und ist äußerst leicht zu erlernen sowie sauber dokumentiert. Damit lässt > sich das gesamte Framework für posix, atmega und mxp430x kompilieren, sowie > die Beispielapplikationen 'HelloWorld' und 'unitTest'. Eine Kurzanleitung > dafür befindet sich in oben genannter Commitnachricht. > > Man kann sowohl die Pakete zu einzelnen Bibliotheken zusammenschnüren als > auch das gesamte Framework zusammen mit der Applikation bauen. Das geht > erstaunlich schnell und problemlos dank QBS. > > Ausblick > -------- > Wichtigstes Ziel ist es, dass erst einmal alle weiterhin zu unterstütztenden > Beispielapplikationen wieder kompilieren. Dazu müssen wir uns bald für ein > Buildsystem entscheiden. Außerdem müssen Testfälle für die einzelnen Pakete > geschrieben werden. Auch dafür braucht es Infrastruktur. > Außerdem ist die Dokumentation bisher auf der Strecke geblieben. Dies wird > nachgezogen, sobald die Struktur stabil ist. > > Nun da der Code entflechtet wurde, ist es übrigens eine relativ leichte > Aufgabe, REFLEX auf eine neue Plattform zu portieren. > > Herzliche Grüße > Richard > > > >
