Date: Tue, 17 Nov 1998 11:05:48 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Andris Pavenis <pavenis AT lanet DOT lv>
cc: Daniel McGrath <dmcg6174 AT yahoo DOT com>, djgpp AT delorie DOT com
Subject: Re: Problem with nested #include's
In-Reply-To: <Pine.A41.4.05.9811162226300.129752-100000@ieva01.lanet.lv>
Message-ID: <Pine.SUN.3.91.981117110530.14078J-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com


On Mon, 16 Nov 1998, Andris Pavenis wrote:

> Specifying full path seems to work with both egcs-1.1 and gcc-2.8.1
> (version of June 1998, I had it on CD, didn't want to mess with
> installing).

I probably should describe the exact exampe where it happens, in case
you didn't see the original message that started this thread.

This is the contents of file.c:

#include "c:/foo/bar.h"

This is the contents of file c:/foo/bar.h:

#include "c:/foo/baz.h"

The contents of c:/foo/baz.h don't matter.

When you compule file.c, CPP complains about baz.h not being there.
But if you change "c:/foo/baz.h" to just "/foo/baz.h", it works.

I'm guessing that, since this is an #include "..." directive, CPP
checks whether the name inside the quotes is absolute, and if not,
appends it to the directory where c:/foo/bar.h is.  So, if CPP thinks
c:/foo/baz.h is not an absolute name, it gets something like
"c:/foo/c:/foo/baz.h", which of course fails.

However, this is all without looking into the sources, so I might be
totally wrong in my guesses.  But the fact is: the above scenario
fails with GCC 2.7.2.1.

> #include  "C:xxxx..." does not work. But does we really need it

My guess is if you solve the nested example above, this C:xxxx thing
will also be solved.  In other words, if CPP knows about DOS-style
file names with drive letters, it will handle the d:foo case correctly
as well.