Hi Sebastian,
> Which command line switch of gcc is preferred for adding include directories?
-I<dir> for user includes.
-isystem <dir> for system includes.
> And: What's the reason that -I modifies system headers includes?
It doesn't.
-I includes are searched before system includes, for #include "blah.h".
-isystem modifies system header includes, which are searched in order by
preprocessor directive #include <blah.h>.
> So, how does the Makefile look like, so that gcc finds Foo/FooWidget.h?
ROOT=/common/project/root
CPPFLAGS=-I${ROOT}
(Well, actually "ROOT" is specified on the Makefile command line:
make ROOT=/common/project/root
... and the /common/project/root is determined algorithmically by the shell
script driver; but that's an implementation detail.)
> How do you avoid that -I. overrides system headers?
It's not a problem that needs to be avoided.
Never use <process.h> when you mean "process.h".
Never use "process.h" when you mean <process.h>.
System headers are specified by #include <...>, and user headers* are
specified by #include "...".
There is a "grey zone". Some SDKs that like to think of themselves as
system headers, and use #include <blah.h> when perhaps (arguably) they
shouldn't ... but let's leave that powder-keg subtopic alone for now.
(Doesn't seem pertinent to you current quandary, anyway.)
> But my question is a little bit more general: There are existing
> projects, which are based on recursive make and automake. They use
> things like -I. by default, which results (as I mentioned) in obscure
> bugs if your files happen to have some "reserved" name -- in my case
> process.h.
That would only be a problem if #include "process.h" is used, when #include
<process.h> was intended.
HTH,
--Eljay
* I'm not sure if the phrase "user headers" is the correct terminology.
