Absender: Simon Siemens
Datum: Fr, 13.05.2011 15:23:33
In-reply-to:
<B3059AA6-A2B6-432F-A08C-6FBF4724F574@xxxxxxxxxxxxxxx>
References:
<1305222936.10999.93.camel@wbam-laptop> <B3059AA6-A2B6-432F-A08C-6FBF4724F574@xxxxxxxxxxxxxxx>
Am Donnerstag, den 12.05.2011, 21:01 +0200 schrieb Timo Sandmann: > den Nutzen sehe ich persÃnlich ehrlich gesagt derzeit auch nicht wirklich. Wenn ich mich richtig an den letzten Stand der Diskussion dazu erinnere, dann war die Ãberlegung, dass zunÃchst eine Bibliothek gebaut wird und diese anschlieÃend (in derselben Konfiguration) verwendet / mit main() zusammen gelinkt wird. Ja, genau darum geht es immer noch. Die entsprechende Ãnderung im Makefile ist recht einfach (etwa 3 Zeilen Ãnderung); ich habe dafÃr schon alles vorbereitet. Wenn du das so gleich haben willst, schicke ich dir dafÃr einen neuen Patch. FÃr die Eclipse-Konfiguration geht das auch. Die Eclipse-Weise, so etwas zu tun, ist, zwei Build-Konfigurationen zu verknÃpfen: Die eine baut die Bibliothek, die andere verbindet die Bibliothek mit der main. > Extra-Targets scheinen mir auch nicht sinnvoll zu sein. Wenn, dann sollte ein Target Bibliothek und Executable bauen. Wie ich oben bereits sagte, ist die VerknÃpfung des Haupt-Targets (elf-Datei) mit der Bibliothek sehr einfach im Makefile zu machen. Dennoch ist es Ãblich, dass wichtige Zwischenschritte einen eigenen Target-Namen bekommen. Im Moment gibt es doch auch schon die phony targets begin, gccversion, sizebefore, build, sizeafter, finished, end, elf, hex, eep, lss, sym, program, coff, extcoff, load, ... Am besten mache ich nÃchste Woche einen Patch fÃr das Makefile, welches den generellen Build-Process gleich in AbhÃngigkeit von der Bibliothek macht. FÃr die Eclipse-Konfiguration schaut das etwas komplizierter aus; darum wÃrde ich hier davon absehen. GruÃ, Simon