Makefile, nur Teilcode kompilieren, lib erstellen und mit Gesamtprojekt linken

[Spice (Gast)]

Hallo Zusammen,

ich habe folgendes Problem, ich möchte ein AVR GCC Projekt teilweise 
kompilieren, daraus eine einzige Datei (Library) bauen und später nur 
die Main.c ändern, neukompilieren und dann mit der Library zu einem 
Hexfile linken. Wie funktioniert sowas genau? Reicht es anhand eines 
Makefiles eine .a Datei von den jeweiligen .c und .h Dateien zu 
erzeugen, dann die .a Datei in AVR Studio hinzufügen und das gesamte 
projekt ohne die .c und .h-Files neu zu kompilieren?
Muss ich dem Preprozessor irgendwelche Inkludierungen mitteilen? Ändert 
sich für die Main.c irgendwas an den Funktionsaufrufen?
Würde mich über jede Antwort freuen...

Besten Dank, Gruß
Spice

[Andreas B. (andreas_b77)]

Statische Libraries (die .a) sind nichts anderes als ar-Archive von 
Objektdateien. Die funktionieren beim Linken nicht anders als eben diese 
Objektdateien, außer dass der Linker nur die Dateien aus der Lib 
einbindet, die auch verwendet werden (die also Symbole exportieren, die 
von anderen Objekten referenziert werden).

Aber ich verstehe die eigentliche Problemstellung nicht. Wozu der 
Aufwand? Wenn das Projekt nicht gerade ein paar tausend Objekten besteht 
braucht make auch nicht sooo viel Zeit um die Abhängigkeiten zu prüfen.

[Kali (Gast)]

>ich habe folgendes Problem, ich möchte ein AVR GCC Projekt teilweise
>kompilieren, daraus eine einzige Datei (Library) bauen und später nur
>die Main.c ändern, neukompilieren und dann mit der Library zu einem
>Hexfile linken.
Das geht.

>Wie funktioniert sowas genau? Reicht es anhand eines
>Makefiles eine .a Datei von den jeweiligen .c und .h Dateien zu
>erzeugen, dann die .a Datei in AVR Studio hinzufügen und das gesamte
>projekt ohne die .c und .h-Files neu zu kompilieren?
Ja. Das reicht. Nur kannst Du regulär keine .a Files mit AVR-Studio 
erzeugen. Dazu musst Du ein eigenes makefile erstellen. Infos dazu gibt 
es im Netz.

>Muss ich dem Preprozessor irgendwelche Inkludierungen mitteilen?
Hm. Wozu dieses krampfhafe Eindeutschung einer "Einfügung"? ;-)
Die Antwort jedenfallls ist ja, sobald Du andere Funktionen als solche 
mit int Rückgabewerten und int Parametern benutzt. Sonst greifen ja die 
Default-Regeln für nicht-deklarierte Funktionen.

>Ändert sich für die Main.c irgendwas an den Funktionsaufrufen?
Nein. C bleibt C.

[Spice (Gast)]

Vielen Dank für die super schnellen Antworten,

ziel ist es eine Lib zur Verfügung zu stellen, wo man nicht direkt sieht 
wieviele object dateien zu dem Projekt gehören. Es sollten so wenig 
dateien wie möglich bei der "Veröffentlichung" zu sehen sein, man soll 
nur an einer Datei main.c "schrauben" können. Und am Ende wird diese 
geänderte Datei mit einer einzigen Library (.a) gelinkt und es soll 
bestenfalls ein Hexfile rauskommen. Lohnt sich der Aufwand nicht? Ich 
könnte auch vorkompilierte object dateien ausliefern, statt die Codes, 
aber ich wollte das aus "schönheitsgründen" vermeiden.

Danke nochmal...
Gruß Spice

[Kali (Gast)]

>ziel ist es eine Lib zur Verfügung zu stellen, wo man nicht direkt sieht
>wieviele object dateien zu dem Projekt gehören?
Was ist daran so nachteilig, wenn man die Anzahl der Dateien ermitteln 
kann. Das interessiert niemanden.

[Spice (Gast)]

Okay, dann werde ich die object dateien ausliefern.

Kann ich den Dateien denn andere Namen geben, wenn ich die 
entsprechenden Stellen im Makefile auch ändere? Sollte kein Problem 
sein, oder !?

Danke nochmal vielmals...
War mir echt eine Hilfe...

Gruß Spice

[Kali (Gast)]

>Kann ich den Dateien denn andere Namen geben, wenn ich die
>entsprechenden Stellen im Makefile auch ändere? Sollte kein Problem
>sein, oder !?

Gib den Dateien doch gleich den Namen den sie im Endeffekt erhalten 
sollen.
Wozu irgendwann noch umbenennen?