On Sun, 2 May 2010 19:17:51 -0700, Barry Smith <bsmith at mcs.anl.gov> wrote: > > Reminder, don't use > > #include "mylocalinclude.h" > > in the PETSc source, you should always make it relative the PETSC_DIR/ > include directory such as > > #include "../src/something/hereiman/mylocalinclude.h"
I'm confused. The standard doesn't say anything about the relative meaning of <file.h> and "file.h", just that each involve an implementation-defined search, and if the search for "file.h" fails, then it should be searched for as if it had been <file.h>. But every compiler I'm aware of follows the POSIX standard (quoting from the description of -I): Change the algorithm for searching for headers whose names are not absolute pathnames to look in the directory named by the directory pathname before looking in the usual places. Thus, headers whose names are enclosed in double-quotes ( "" ) shall be searched for first in the directory of the file with the #include line, then in directories named in -I options, and last in the usual places. For headers whose names are enclosed in angle brackets ( "<>" ), the header shall be searched for only in directories named in -I options and then in the usual places. Directories named in -I options shall be searched in the order specified. In lieu of a compiler doing it differently, it would be correct to #include <petscsnes.h> and #include "mylocalinclude.h" (or #include <../src/something/hereiman/mylocalinclude.h>, but I think the former is more maintainable). This is certainly the convention I see in almost all other projects. Is the current way of doing things dictated by strange compilers or the documentation tools? Jed
