"Dave Korn" <[EMAIL PROTECTED]> writes: > Here's one: it doesn't involve -iquote, but I think it illustrates the same > problem.
The problem which Mike described had to do with #include_next. So I don't think this is the same problem. > 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). I would describe this as a bug in the libstdc++ header files. They do this: #include <debug/debug.h> That is a bad idea because if the user uses a -I option which happens to point to a debug/debug.h file, the wrong debug.h file will be picked up. The libstdc++ header files should probably do this: #include "debug/debug.h" Then the search will start from the location of the libstdc++ header file, and the preprocessor will always find the right header file. This is a consistent issue throughout the libstdc++ header files. > 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. Yes, and the -I- option has been deprecated because it doesn't do the right thing. Instead, we have -iquote. And we are currently missing -idisable-the-directory-of-the-including-file, which is a bug. Unfortunately, using -idisable-the-directory-of-the-including-file will break my suggestion of using #include "" in the libstdc++ header files. But using #include <> in those header files is also wrong. I'm not sure how to resolve that. Ian
