SCons stat make für avr gcc

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