Re: Preprocessor: Einbinden von Header Dateien
Manfred Hollstein <[email protected]>
| Newsgroups | gmane.linux.suse.programming |
|---|---|
| Message-ID | <[email protected]> |
Moin, On Sat, 25 Oct 2008, 14:25:24 +0200, Thomas Hertweck wrote: > > Folgendes Szenario: > > Es sei die folgende Verzeichnisstruktur gegeben: > > ./include > |-> first.h > |-> second.h > ./src > |-> code.c > > Der Quellcode code.c bindet die Datei first.h ein, diese Datei wiederum > bindet die Datei second.h ein. Der Quellcode wird im Verzeichnis ./src > mit dem Befehl "gcc -I. -I../include" usw. uebersetzt - das funktioniert > wie erwartet. > > Nun arbeitet jemand am Quellcode und macht eine lokale Kopie der Datei > second.h, um dort z.B. ein weiteres Makro zu definieren. Die > Verzeichnisstruktur sieht dann wie folgt aus: > > ./include > |-> first.h > |-> second.h > ./src > |-> code.c > |-> second.h > > Die Frage ist nun, welche Datei second.h wird letztendlich verwendet, > wenn der Code im Verzeichnis ./src wiederum mit dem Befehl "gcc -I. > -I../include" usw. uebersetzt wird. Ich haette eigentlich erwartet, dass > es die lokale Datei second.h ist, die eingebunden wird. Dem ist > allerdings nicht so, wie auch die von gcc ausgegebenen Abhaengigkeiten > zeigen: > > code.o: code.c ../include/first.h ../include/second.h > > Meine Compilierung schlaegt daher fehl, da meine Aenderungen in der > lokalen second.h in ./src nicht bekannt sind. Lasse ich mir > Abhaengigkeiten mit makedepend generieren, so verhaelt es sich anders: > > code.o: code.c ../include/first.h second.h > > Damit ist zwar dann die Abhaengigkeit wie ich sie erwartet haette, aber > das Compilieren schlaegt natuerlich nachwievor fehl, da dort ja der > Preprocessor zum Einsatz kommt und die "falsche" Datei einbindet. Lang, lang ist's her... Wenn ich das noch richtig in Erinnerung habe, spielt vor Allem die Art und Weise, _wie_ das File include't wird, eine Rolle. Wenn Du's mit #include "second.h" ranziehst, wird -I. relativ zu dem File, aus dem die #include Anweisung kommt betrachtet, also relativ zu "../include" ... Wenn du das Ding aber wie ein System-Includefile betrachtet sehen willst, dann solltest Du #include <second.h> benutzen. Zumindest findet ein "gcc -M -I. -I../include code.c" dann bei mir auch das second.h aus ./src und nicht aus ../include . > Wenn ich ebenfalls eine lokale Kopie von first.h in ./src anlege, dann > wiederum funktioniert die Sache. Ich verstehe also, was passiert und wie > der Preprocessor die -I Optionen handhabt: er scheint beim Einbinden von > Header Dateien in anderen Header Dateien nicht wieder alle > Verzeichnisse, die ueber -I spezifiziert sind, durchzugehen. Das finde > ich etwas seltsam. > > Die Frage ist nun: Bug oder Feature? Bzw. wer handhabt die Sache > korrekt, der Preprocessor oder makedepend? Wie gesagt, wenn ich das noch richtig in Erinnerung habe (ist mittlerweile so groessenordnungsmaessig 12 Jahre her ;-), wuerde ich das als Feature bezeichnen; funktioniert zumindest so, wie ich's immer benutzt hatte. > Gruesse, > Thomas > > PS: System ist opensuse 10.3 mit gcc 4.2.1 und makedepend aus > xorg-x11-util-devel 7.2. Hmm, ich habe makedepend nie benutzt, sondern immer nur entsprechende Regeln im Makefile, die "gcc -M" selber genutzt haben. HTH, cheers. l8er manfred