Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!bbn!bbn.com!jgrace
From: jgrace@bbn.com (Joe Grace)
Newsgroups: comp.lang.c
Subject: Why don't nested #include's start at the source directory?
Keywords: cpp
Message-ID: <49549@bbn.COM>
Date: 12 Dec 89 02:43:13 GMT
Sender: news@bbn.COM
Reply-To: jgrace@BBN.COM (Joe Grace)
Followup-To: comp.lang.c
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 46

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>