Hi, ich bin eine der make geplagten Seelen. Ich weiß nicht wieso, aber ich bin mit make bisher nie klargekommen. Gestern bin ich auf SCons gestoßen und war sofort begeistert. Es macht eigentlich nichts anderes als make, nur irgendwie einfacher. Außerdem hat man den vollen Funktionsumfang von Python zur Verfügung wodurch ganz andere Möglichkeiten entstehen. Es hat mich so begeistert das ich gleich mal einen Artikel darüber schreiben musste. http://wiki.elektronik-projekt.de/mikrocontroller/avr/scons_avr Was haltet ihr davon?
Hallo MarkusB, bin selbst von SCons auch begeistert... verwende es jetzt praktisch ausschließlich in meinen (Nicht-)AVR-Projekten. Für AVR sollte man ein eigenes Tool schreiben, vielleicht investierst Du ja darein etwas Zeit ? Beim AVR benutze ich immer noch ein Makefile (basierend auf einem Template). Seit der neuen Version 0.98.5 läuft es auch endlich vernünftig schnell los. Die mangelnde Geschwindigkeit bis es bei großen Projekten (ca. 400 kLOC) losläuft, hatte mich immer gestört. Nach Portieren unseres Projektes von imake (ja, ist steinalt) auf SCons hing die Anzahl der Zeilen für das Build-System auf etwa 40% zurück, jetzt ist es etwas mehr, wir haben eine Reihe von Custom-Buildern geschrieben/übernommen (Corba, RPC z.B.) sowie einige Tests wie man sie von den GNU autotools her kennt. Einen Vorteil gegenüber make-basierenden Build-Tools sehe ich darin, dass die Verzeichnisstruktur für die Reihenfolge der Übersetzung nicht relevant ist. Bei uns gab es einige Verschiebungen, da war dann die Struktur durch CVS leider fest - mit subversion hätten wir diese Probleme nicht gehabt. Wir benutzen auch ccache und distcc, das läßt sich sehr elegant benutzen und läuft meistens auch recht gut. Allerdings ist es recht schwierig, wenn man andere Compiler/Platformen verwenden will wenn sie nicht schon eingebaut sind. Mein Ausflug zum ICC (Intel-Compiler) war damals ein Trauerspiel... War wohl auch der Grund warum KDE gleich wieder von SCons auf CMake umgeschwenkt ist. Wenn man übrigens auf eine andere SCons-Version umschwenkt, tut man gut daran, ein 'scons -c' zu machen, die internen Files sind wohl recht unterschiedlich. Viel Spaß damit Hermann-Josef
Hi Hermann-Josef, >Für AVR sollte man ein >eigenes Tool schreiben, vielleicht investierst Du ja darein etwas Zeit ? Was meinst du mit "eigenem Tool"? Wie ich in meinem Artikel geschrieben hab funktioniert das ganze schon mit dem avr-gcc. Ich hab zwar außer dem Beispiel noch nichts ausprobiert, aber ich denke man sollte alles machen können was make auch kann
Hallo MarkusB, war nur ein etwas eigennütziger Vorschlag das zu perfektionieren, dann könnte ich in Zukunft auch davon profitieren. Aber wie Du gezeigt hast, geht es ja schon mit weniger Aufwand. In dem Tool (oder sollte man es besser Modul nennen ? ... bin mit Python noch nicht so bewandert) würde u.a. Folgendes gemacht: - Setzen von Variablen wie z.B. CC oder CCFLAGS bzw. Namen von Compiler, Linker etc. - Bereitstellung zusätzlicher Kommandos wie z.B. *.elf -> *.hex o.ä. - Hinzufügen von Buildern und Emittern (SCons-Slang) In der SCons-man-page wird sowas als Tool bezeichnet. Natürlich geht es für eine bestimmte Platform immer, direkt etwas an die Kommandozeile durchzureichen (auc bei make), aber platformunabhängig ist das dann nicht. Das Tool würde das Umschalten von z.B. avr-gcc auf avr-gcc.exe automatisch machen - natürlich muss das vorher auch jemand in das Tool einprogrammiert haben. Ich selbst habe sowas auch noch nicht gemacht, ich weiß nur dass es das gibt, bzw. benutze es nur für doxygen und Qt, so fügt beispielsweise dieses Fragment
1 | Import('env')
|
2 | |
3 | my_env = env.Clone(tools = ['qt']) |
dem SCons das "Wissen" hinzu, wie man *.ui-Dateien sowie den moc für Qt-basierende Anwendungen richtig benutzt. Dann kann man einfach schreiben:
1 | srcs = Split('main.cc Window.ui')
|
2 | |
3 | my_env.program('program',srcs)
|
Hermann-Josef
Achso, ich verstehe was du meinst. Ja, kann man machen. Ich werde da sicher noch ein bisschen mehr machen. Fang ja gerade erst damit an. Python ist sowieso meine Lieblingssprache
Hallo MarkusB, Hermann-Josef,
privat und in der Firma setze ich seit längerem scons ein, auch für avr
Projekte. Das langsame Starten ist mir vor allem bei Windows
aufgefallen, wenn Netzlaufwerke im Spiel waren. Da verkehrt sich der
Vorteil von Scons, die Abhängigkeiten per Hash-Summe zu prüfen ins
Gegenteil, weil jedes der beteiligten Files komplett von der Platte
gelesen werden muss.
Ein anderer Vorteil von Scons ist, dass man sich nicht um die sekundären
Abhängigkeiten (Include-Files) kümmern muss und problemlos verschiedene
Compiler / Codegeneratoren, etc. miteinander verheiraten kann. "scons
-c" braucht man wirklich nur ganz selten.
Weiterhin bringt scons viele nützliche Tools, die installieren,
kopieren, packen, ....
Ein paar Anmerkungen zum Artikel und zur Verwendung von scons
hätte ich noch:
- möglichst der Versuchung wiederstehen, mit python direkt im
Sconscript zu arbeiten, das macht den Code nur unübersichtlicher und
es kann zu komischen Seiteneffekten kommen, also besser:
env['F_CPU'] = "16000000UL"
env['CCFLAGS'] = "... -DF_CPU=$F_CPU"
- möglichst die eingebauten Mechanismen verwenden, also
* env['CPPPATH'] += Split("./inc ../inc")
anstelle von
* env['CCFLAGS'] = "... -Iinc -I../inc"
- sinnvoll für ein plattformunabhängiges Buildscript ist die
Generierung der Umgebung mit
* env = Environment(tools=['gcc'])
ansonsten nimmt Scons auf einem nicht-posix (Windows) System an, dass
u.a. die Optionen im Windows-Style genutzt werden, die Kommandozeile
würde dann mit "/Iinc" statt "-Iinc" aufgebaut und vom avr-gcc nicht
verstanden.
- Vorsicht vor der Zeile env.Clean('tusnicht','') die löscht den
Sourcebaum zuverlässig (... ja ich hatte ein Backup)
- wenn man die Übersicht über die Dateiabhängigkeiten verloren hat,
hilft "scons --debug=tree"
Bleibt nun zu hoffen, dass früher oder später scons-local mit WinAVR
geliefert wird ;-)
Beispiele für ein etwas umfangreicheres Scons/AVR Projekt findet man
unter http://www.nongnu.org/uracoli
Gruss, Axel
PS: Von cmake war bei Hermann-Josef auch die Rede, damit bin ich mit den
avr tools allerdings nicht so recht klar gekommen, trotz Kauf des
Buches.
Hi Axel, danke für die Infos. Ich werd die Ratschläge beherzigen. Ich kenn SCons erst seit zwei Tagen, aber ich werd mir mal anschauen was du in deinem Projekt da alles anstellst. Ich muss gestehen das ich keine Ahnung habe wozu man das alles braucht Gruß Markus
So, ich habe das SConstruct etwas überarbeitet und eine kleine Referenz hinzugefügt http://www.wiki.elektronik-projekt.de/mikrocontroller/avr/scons_avr @Axel: das Beispiel von uracoli bereitet mir bis heute Kopfschmerzen ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.