On 27 September 2006 01:49, Ian Lance Taylor wrote:
> Mike Stump <[EMAIL PROTECTED]> writes:
>> and this can find a user limits.h in a directory named with -iquote
>> whenever -I- isn't used. The user wishes to not so find that file, as
>> it breaks <limits.h>/<syslimits.h> on the system.
>
> My understanding has always been that #include_next should find a
> version of the header file farther down the search path. So if gcc's
> limits.h was found via #include <limits.h>, then the #include_next
> should not find a #include "limits.h", it should find the next
> <limits.h>.
>
> And that is pretty much what the documentation says. And I don't
> think that behaviour should change in any way.
>
> So I don't understand what the issue is. Can you give an example?
Here's one: it doesn't involve -iquote, but I think it illustrates the same
problem.
----------------------------------<snip>----------------------------------
pushd /tmp
mkdir -p source source/debug source/main
cat <<EOT > source/main/main.cc
#include <iostream>
int main (int argc, const char **argv)
{
std::cout << "Hello world." << std::endl;
}
EOT
touch source/debug/debug.h
g++ -I source source/main/main.cc -o main
----------------------------------<snip>----------------------------------
One of the STL headers finds our user-appplication debug/debug.h instead of
./debug/debug.h, which is what it expects to find (umm, I don't really mean
"." in the $PWD sense, I mean it in the sense of the directory where the STL
header lives).
It used to be possible to work around this problem by using -I- to split the
path and relying on <> includes to only pick up on system files. That's not
always an option ever since the change that made -I- /also/ prevent include
files located side-by-side in the same directory from finding each other
without a full path. As it says in the manual,
" In addition, the `-I-' option inhibits the use of the current
directory (where the current input file came from) as the first
search directory for `#include "FILE"'. There is no way to
override this effect of `-I-'. With `-I.' you can specify
searching the directory which was current when the compiler was
invoked. That is not exactly the same as what the preprocessor
does by default, but it is often satisfactory. "
Heh, "not exactly the same". Not remotely the same, and as a consequence,
if you were relying on the search-the-same-dir-first behaviour, there is no
workaround (that I have been able to imagine) except to find any headers in
your project that happen to match private headers used by the standard system
headers and add a #include_next and have this horrible scheme of proxying an
STL header's #include of it's own private header via your own source tree.
Ugh!
It would resolve the issue if these two unrelated behaviours of -I- were
separated.
cheers,
DaveK
--
Can't think of a witty .sigline today....
