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

[Jed Brown]

On Mon, 3 May 2010 14:06:54 -0700, Barry Smith <bsmith at mcs.anl.gov> wrote:
>     The reason for it is to disconnect the location of a source file  
> from "its" include files. Otherwise you have the implicit assumption  
> that a source file is compiled in the directory that it is sitting it.  
> I want the freedom to compile source code with NO assumption as to  
> where it is sitting. That is the freedom to compile code in a  
> different way then the traditional recursive make that PETSc uses to  
> build its libraries. (One simple reason is that the traditional  
> recursive make is damn slow).

The POSIX resolution semantics don't have anything to do with the
compiler's working directory ($PWD), it has only to do with the location
of the file.  Using the full path makes sense if you want to relocate
*.c files *without* moving their accompanying headers (you'd have to
edit the file if you wanted to use a relocated header).  In this case,
it would still be (more) correct to include the header with angle
brackets instead of quotes (because correctness requires that the header
is *not* found by following the path from the directory where the source
file resides, we're relying on the header being found only after falling
back to angle-bracket semantics).

If you really want the source files to be compilable after copying them
out of the source tree, without also copying the accompanying header,
then it would seem cleaner to drop all the implementation headers into
include/private (though I prefer keeping implementation headers in the
source tree and including them with "thisimpl.h", the whole point is
that these files are private to that implementation).

I hate recursive make, not only is it slow, the dependency analysis is
incorrect.

Jed