[petsc-dev] reminder never use #include "mylocalinclude.h" in PETSc source

[Jed Brown]

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