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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.