Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!hstbme.mit.edu!scs
From: scs@hstbme.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: source for included included files
Message-ID: <14172@bloom-beacon.MIT.EDU>
Date: 9 Sep 89 04:06:29 GMT
References: <9275@cbnews.ATT.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 51

In article <9275@cbnews.ATT.COM> mveao@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