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

[Barry Smith]

On May 3, 2010, at 2:23 PM, Jed Brown wrote:

> 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).

   Perhaps we should change them to use <>
>
> 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

    It is best to keep them with their corresponding source code.

    Eventually our source code won't even live directly on the file  
system nor found by looking in the file system.

    BTW: the reason I cared yesterday and "complained" about the very  
small number of "wrong" files was my attempt to get PETSc source into  
a GUI based development system (Xcode in particular, but Eclipse and  
Developer Studio are other important cases). Currently PETSc handles  
active and inactive source code (depending on what configure options  
are used) by "markers" in the makefiles. GUI systems don't/cannot  
understand these so my solution is to build links to the active source  
code that can then be easily passed to the GUI system. This breaks if  
you assume the .h files are in the same directory as the .c.

    Barry


> 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