".c"-Sourcefiles nur dem Projekt mitteilen und nicht im Code?

[noch-am-Anfang (Gast)]

Sorry für die dummen Fragen aber ich bin ein totaler C- newbee:

Die Aufteilung in C und h Dateien habe ich dank vieler Forumbeiträge 
schon kapiert (glaube ich zumindest).

Aber die einzelnen C-Dateien müssen nirgends im Code erwähnt werden?
Ich habe nämlich gerade ein Beispielprojekt von Microchip geöffnet 
(siehe screenshot) und die C-Dateien sind nur im Projektbaum unter 
"source-files" aufgeführt.

1. Frage:
D.h. der "Projektmanager" (hier MPLABX) sorgt dafür, dass alle c-files 
gefunden und irgendwann compiliert werden?

2.
Aber es gibt doch sicherlich auch Kommandozeilen C-compiler. Hier müssen 
dann doch irgendwie alle .c-files aufgelistet werden? Oder gibt es hier 
eine spezielle Datei (wie .lnk oder .mkr nur als Vergleich), in welchen 
die Dateien dann benannt werden müssen.
Oder sucht der Compiler automatisch nach einer xy.c-Datei, wenn irgendwo 
eine headerdatei xy.h eingebunden wird?

Danke schon mal...

[Mark B. (markbrandis)]

noch-am-Anfang schrieb:
> 1. Frage:
> D.h. der "Projektmanager" (hier MPLABX) sorgt dafür, dass alle c-files
> gefunden und irgendwann compiliert werden?

Ja, sofern sie dem Projekt hinzugefügt wurden für das sie übersetzt 
werden sollen.


> 2.
> Aber es gibt doch sicherlich auch Kommandozeilen C-compiler. Hier müssen
> dann doch irgendwie alle .c-files aufgelistet werden?

Ja. Das geschieht zum Beispiel in so genannten Makefiles.

[noch-am-Anfang (Gast)]

Danke,
Held der Hochgeschwindigkeitsantwort!

[Walter S. (avatar)]

Mark B. schrieb:
>> Aber es gibt doch sicherlich auch Kommandozeilen C-compiler. Hier müssen
>> dann doch irgendwie alle .c-files aufgelistet werden?
>
> Ja. Das geschieht zum Beispiel in so genannten Makefiles.

oder das andere Beispiel: direkt in der Kommandozeile

[A. S. (Gast)]

gcc a.c b.c .\dir1\*.c ..\mylib\doit.c

[Dirk B. (dirkb2)]

noch-am-Anfang schrieb:
> Oder sucht der Compiler automatisch nach einer xy.c-Datei, wenn irgendwo
> eine headerdatei xy.h eingebunden wird?
Nein.

Und auch der Compiler kann mit dem Makefile nichts anfangen.
Dafür ist das Programm make da. Und das ruft den Compiler auf.

[I <3 Makefiles! (Gast)]

> Und auch der Compiler kann mit dem Makefile nichts anfangen.
> Dafür ist das Programm make da. Und das ruft den Compiler auf.

Und zwar ruft Make den Compiler sooft auf, wie es gemäss den im 
projektspezifischen Makefile beschrieben wird.
Je nach Parameter die man Make mitgibt, geschieht dies strikt 
sequentiell (und dauert) oder so parallel wie es die im 
projektspezifischen Makefile vorgegebenen Abhängigkeiten zulassen (und 
ist meist deutlich schneller)

Die "Projektangaben" in den diversen GUI-DIEs versuchen das Äquivalente 
zu Makefiles zu sein

Beiden Wege ist gemeinsam dass alle Quelldateien eines Projektes bekannt 
sein müssen.

Die Logik, nach der in GUI-IDEs mit den Quelldateien die 
Compile-Reihenfolge und den Compile-Bedarf *für C/C++* ermittelt wird, 
ist nur für sauber strukturierte Projekte (von trivialer Struktur) 
erfolgreich, im Zweifel langsam.

Im übrigen ist Make weder auf C/C++ im Speziellen noch auf Programmieren 
im Allgemeinen festgelegt.
Make ist überall da nützlich wo aufgrund später modifizierten 
"Eingabe"-Dateien, davon abgeleitete "Ausgabe"-Dateien neu zu 
produzieren sind, unter Aufruf beliebigen, (nicht-interaktiven) 
Transformationsprogramme. Bsp.: *.c --> cc --> *.o

Aufgrund der in C/C++ definierten "Einschränkung" dass pro 
Compileraufruf nur das bekannt ist was in der Quelldatei steht 
(allenfalls #include-iert ist), ist Projektorganisation etwas das nicht 
Sprachintrinsisch ist und somit zwingend ausserhalb des Compilers 
gemacht werden MUSS.


Man ist frei dies auch in einem simplen, sturen, linearen Script/Batch 
zu erledigen.

[noch-am-Anfang (Gast)]

Danke nochmal!

Vermutlich lernt man das alles in der ersten Informatikstunde.
Als Quereinsteiger ist es etwas mühsam, hier eine schnelle Erleuchtung 
zu finden.

Auch wenn es tausende C-Bücher gibt, solche Grundprinzipien habe ich 
bislang vergeblich gesucht (zumindest in den Büchern, die hier 
rumliegen).
Weil das offenbar zu banal ist...

[Dennis S. (eltio)]

noch-am-Anfang schrieb:
> Vermutlich lernt man das alles in der ersten Informatikstunde.
> Als Quereinsteiger ist es etwas mühsam, hier eine schnelle Erleuchtung
> zu finden.

Nein, keine Sorge. Ist nicht ungewöhnlich, dass sowas erst später kommt.

[Baku M. (baku)]

Vielleicht noch zur Verklarung:
'Make' hat, wie schon gesagt, mit dem Compiler eigentlich nichts zu tun, 
es automatisiert nur, was man auch von Hand machen kann:
Jedes .c-File wird vom Compiler einzeln übersetzt, in ein .obj-File.
Das alleine ist noch nicht lauffähig.
Wenn alle .c-Files übersetztz sind, kommt am Ende der Linker, und der 
muß dann alle .obj-Files kennen (und noch ein wenig mehr).
Der Linker baut alle .obj-Files (können auch .o heissen)zu einem 
ausführbaren Programm zusammen, nimmt eventuel noch einige fertige 
Libraries dazu und fertig.

Diese Vorgehensweise hat den netten Vorteil, daß man (oder Make) nur 
geänderte Dateien neu übersetzen muß und nicht alles.

HTH
Baku

Edit: .obj oder .o