source for included included files
Steve Summit
scs at hstbme.mit.edu
Sat Sep 9 14:06:29 AEST 1989
In article <9275 at cbnews.ATT.COM> mveao at cbnews.ATT.COM (eric.a.olson) writes:
> I have a file that needs to include 30 or so other files.
> The original author wrote it to include "all.h" where
> "all.h" includes the other 30 files.
> The preprocessor seems to want to look for the second-level
> included files in the same directory where the "all.h" file
> was found. A local copy of a second-level .h file is totally
> ignored unless "all.h" is in the first view.
> Is this normal behavior?
Yes. It is a not-universally-known and possibly surprising fact
that #include with double quotes searches in the directory of the
file doing the #including, not (necessarily) in the current
directory from which the compiler was invoked.
I am currently working on a large project, various versions of
which are compiled in different directories, referencing source
files in one master directory. So that I can "tune" the builds
with special header files in the various build directories, I
occasionally use angle brackets instead of double quotes:
#include <tunable.h> /* <> so copy in directory other than that */
/* of source file can be selected with -I */
The CFLAGS macro in my Makefile then always contains -I. (The
trick applies only to a handful of header files for which I wish
multiple versions to exist; most project-related header files are
kept in the master source directory, and #included with double
quotes, making the default behavior for double quote searching
useful and correct. In fact, that's probably why the behavior
was designed that way.)
The rules for #include file searching can seem capricious at
first, but it's surprising how many useful effects you can
achieve by using them knowingly.
Note that the search behavior is quite implementation-defined.
I have described the Unix behavior; other systems generally try
to emulate it, with varying degrees of success. The ANSI
standard says, according to K&R II (sec. A12.4), that "a control
line of the form
#include "filename"
searches first in association with the original source file (a
deliberately implementation-dependent phrase)" and then in
whatever other places that #include <filename> would search.
The pANS does not require that there be the notion of a
directory, nor probably that there be the notion of a "source
file."
Steve Summit
More information about the Comp.lang.c
mailing list