Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!psuvm!psuecl!c9h
From: c9h@psuecl.bitnet
Newsgroups: comp.lang.c
Subject: Re: Why don't nested #include's start at the source directory?
Message-ID: <72093@psuecl.bitnet>
Date: 13 Dec 89 21:19:59 GMT
References: <49549@bbn.COM>
Followup-To: comp.lang.c
Organization: Engineering Computer Lab, Pennsylvania State University
Lines: 45

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