jgrace@bbn.com (Joe Grace) (12/12/89)
I have found a surprising, annoying and disappointing "feature" of
both /lib/cpp (SunOS3.5) and GNU cpp:
Given the files:
./foo.c:
#include "1.h"
./bar/1.h:
#include "2.h"
./2.h:
2 /* Just anything; cpp never finds this file! */
> /lib/cpp -Ibar foo.c # produces:
# 1 "foo.c"
# 1 "bar/1.h" 1
bar/1.h: 2: Can't find include file 2.h
[Uhhh, no! You can't find file ./bar/2.h but ./2.h certainly exists.
Why don't you use ./2.h? And if both bar/2.h and ./2.h exist, I would
still want you to use ./2.h.]
# 2 "foo.c" 2
Now, 1.h exists in . so what's the problem? This behavior seems both
buggy and undesirable to me. On the other hand, it seems unusual that
this is a normal "bug" since one has to go to trouble (i.e., has to
try) to get this behavior.
[By the way, if you add -I. to the command line, cpp finds ./2.h --- fine.
Unfortunately, if you have both a ./2.h *and* a bar/2.h, it finds
bar/2.h instead of ./2.h (Argghhrrrr --- this is actually where I
need the other behavior!).]
Is this behavior generally broken or am I missing something?
Thanks,
= Joe =
(followup-to: comp.lang.c)
Joe Grace
ARPA: jgrace@bbn.com
UUCP: {harvard,husc6,decvax,etc.}!bbn!jgrace
#include <StandardDisclaimer.h>henry@utzoo.uucp (Henry Spencer) (12/13/89)
In article <49549@bbn.COM> jgrace@BBN.COM (Joe Grace) writes: >Is this behavior generally broken or am I missing something? The problem is that K&R1 was not entirely explicit about how things happened when #includes got nested. Some compilers look for #include "..." in the directory of the first source file, some look for it in the directory of the current source file. (ANSI C just says that it is implementation-defined, with a strong hint in the Rationale that first-source-file behavior is preferred.) The only portable way to deal with the situation, insofar as there is one, is to use #include <...> and -I to get the rules you want. -- 1755 EST, Dec 14, 1972: human | Henry Spencer at U of Toronto Zoology exploration of space terminates| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
desj@idacrd.UUCP (David desJardins) (12/13/89)
From article <49549@bbn.COM>, by jgrace@bbn.com (Joe Grace): > I have found a surprising, annoying and disappointing "feature" of > both /lib/cpp (SunOS3.5) and GNU cpp: > > ./bar/1.h: > #include "2.h" The behavior looks perfectly correct to me. The meaning of the file 1.h should not depend on where you compile it from. Looking at the file by itself, obviously the place to look for 2.h is in the directory where 1.h is found. If you want it to find 2.h in the .. directory, then write #include "../2.h". -- David desJardins
c9h@psuecl.bitnet (12/14/89)
In article <49549@bbn.COM>, jgrace@bbn.com (Joe Grace) writes: > I have found a surprising, annoying and disappointing "feature" of > both /lib/cpp (SunOS3.5) and GNU cpp: > > Given the files: > > ./foo.c: > #include "1.h" > > ./bar/1.h: > #include "2.h" > > ./2.h: > 2 /* Just anything; cpp never finds this file! */ > >> /lib/cpp -Ibar foo.c # produces: > # 1 "foo.c" > > # 1 "bar/1.h" 1 > > bar/1.h: 2: Can't find include file 2.h > [Uhhh, no! You can't find file ./bar/2.h but ./2.h certainly exists. > Why don't you use ./2.h? And if both bar/2.h and ./2.h exist, I would > still want you to use ./2.h.] > # 2 "foo.c" 2 > > > Now, 1.h exists in . so what's the problem? This behavior seems both > buggy and undesirable to me. On the other hand, it seems unusual that > this is a normal "bug" since one has to go to trouble (i.e., has to > try) to get this behavior. Whether or not this is a bug is a matter of opinion. When you use quotes around the filename in an #include statement, this generally means to search in the *same* directory. Now, here arises the question: The same directory as the file with the #include, or the same directory as the main program? Personally, I prefer the former. -- - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" c9h@psuecl.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@eclx.psu.edu "Mem'ry, all alone in the moonlight ..." c9h@hcx.psu.edu cmh@psuecl2.bitnet