Hi Leute, Folgendes Problem vermiest mir gerade den Rutsch ins neue Jahr: Ich lerne gerade den Umgang mit Make, weil mir das manuelle Kompilieren von mehreren Dateien auf dauer nervig ist und der einzige mir bekannte Ausweg die #include'ierung von C-Dateien ist, was allerdings schlechter Stil ist. Ich verwende den SDCC als Compiler, und dort muss man (soweit ich das richtig verstanden habe) erst unter Angabe der Header die C-Dateien in .rel-Dateien kompilieren und dann alle .rel-Dateien auf einmal verlinken. Soweit klappt es auch. Nun hab ich allerdings die SPL-Lib von STM, für den SDCC gepatcht, heruntergeladen und will diese einbinden. Das kann ich natürlich tun, wenn ich die Quelldateien einzeln angebe - bei einer Datei pro SPL-Funktion ist das aber aus Bequemlichkeitsgründen ausgeschlossen. Andere Möglichkeit wäre es, alle SPL-Dateien auf einmal zu kompilieren, was allerdings an Dateien scheitert, die nicht zum verwendeten µC gehören. Z.B. mit CAN kann SDCC nichts anfangen, weil es kein CAN in meinem STM8S105 gibt. Ich vermute, es wird einen Mechanismus geben, entweder im SDCC oder im Make selber, um eine Relation zwischen verwendeten Funktionen und den Dateien, die diese Funktionen enthalten, zu erstellen und ausschließlich die Dateien zu kompilieren, die auch Funktionen erhalten, die verwendet werden. Alles andere wäre auch Rechenzeitverschwendung, oder? TL;DR: Wie lässt man mit Makefile den SDCC nur Dateien kompilieren, deren Funktionen verwendet werden? MfG, Viktor
Du willst zwei Sachen auf einmal. 1. Deine Library enthält Peripherie, die auf deinem μC nicht existiert. a) immer "die ganze Lib" kompilieren, aber durch Compilerswitch die für einen μC relevanten Teile explizit einschalten. Make muss also einen Compilerswitch an den Compiler übergeben. Kann auch durch den Compiler gesetztes μC-define sein, welches dem Compiler als Kommandozeilenparameter übergeben wurde. Wird z.B. beim avr-gcc so gemacht. b) nur die relevanten Teile der Lib kompilieren, dazu im makefile die projektspezifischen und die μC-spezifischen .rel-files definieren. Je nach zentral im makefile eingestelltem μC wird die passende μC-spezifische .rel-Liste ausgewählt. c) eine Kombination aus a) und b) 2. Du willst, dass nicht verwendete Funktionen nicht im binary landen. Das macht ein halbwegs schlauer Compiler oder auch optimizing Linker von selbst. Der SDCC tut es jedenfalls. mfg mf
:
Bearbeitet durch User
Viktor B. schrieb: > Nun hab ich allerdings die > SPL-Lib von STM, für den SDCC gepatcht, heruntergeladen und will diese > einbinden. Das kann ich natürlich tun, wenn ich die Quelldateien einzeln > angebe - bei einer Datei pro SPL-Funktion ist das aber aus > Bequemlichkeitsgründen ausgeschlossen. Gibt es dort eventuell schon ein Makefile? Dann könnte man eventuell etwas machen in die Richtung:
1 | libs/spl-lib.a: |
2 | $(MAKE) CC=sdcc LD=sdcc IRGENDWAS=abc repo/spl-lib/spl-lib.a |
3 | cp repo/spl-lib/spl-lib.a libs/spl-lib.a |
Wobei, kann sdcc überhaupt statische libraries? sdcc scheint auch anderweitig recht eigen zu sein, .rel statt .o, und kennt es mittlerweile -o "target"?, etc. Bei nem guten compiler & guten Makefiles würde ich sonst erwarten, dass man einfach CC, LD, AR und eventuell noch CFLAGS/LDFLAGS setzt, und gut ist, aber ob das mit dem Ding machbar ist...
Edit: Zu schnell abgeschickt, etwas in der Form:
1 | libs/spl-lib.a: |
2 | $(MAKE) CC=sdcc LD=sdcc IRGENDWAS=abc -C repo/spl-lib/ spl-lib.a |
3 | cp repo/spl-lib/spl-lib.a libs/spl-lib.a |
Bitte 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.