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
