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

[Barry Smith]

On Mar 14, 2011, at 8:44 AM, Jed Brown wrote:

> On Mon, Mar 14, 2011 at 14:08, Barry Smith <bsmith at mcs.anl.gov> wrote:
> For files like aij.h if you use the localinclude.h paradigm then in aij.c you would have  #include "aij.h"  but in mpiaij.h you would have #include <./src/mat/impls/aij/seq/aij.h> I don't like the fact that in different files the sameinclude is referenced in a different way. Now one could argue that private includes used ONLY locally use the "localinclude.h"  model and private includes used more than locally use the <../src/path/to/localinclude.h> but why?
> 
> So that they can be built independently from the source tree.
> 
> Better the simplicity of always using the <../src/path/to/localinclude.h> model.
> 
> There are at least four approaches
> 
> 1. #include "../seq/aij.h"

yuck

> 
> 2. #include <../src/mat/impls/aij/seq/aij.h>
> 
> 3. Have the build system add -I$PETSC_DIR/src/mat/impls/aij/seq and use #include <aij.h>

  yuck

> 
> 4. Move this not-truly-private header to include/private/matseqaij.h and #include <private/matseqaij.h>.

  What bothers me about this one is that private has no hierarchy and will eventually become cluttered with all kinds of stuff from many different places in PETSc.

  The reason private was introduced (rather than having all of the private includes directly in the source tree) was sometimes external tools (Lisandros python stuff?) needed access to the files with a --prefix install so it had to go in the include directory. I really like having it in the source (I could give a shit about parts of PETSc source being built independently from the source tree).  Maybe the private includes should be fixed up to contain (1) what is truly needed in the --prefix directory hence must in the include tree and what (2) belongs somewhere in the source tree.


   Barry

> 
> 
> 1 permits relocating part of the source tree and compiling (a variant of) a single module without changing includes. 2 requires modifying all derived implementations if the header is relocated and only works if the full source tree is available. 3 is the same, but the change is only to the build system and the build system is more easily "aware" of this cross-dependency. 4 is a direction that we have already been going over the past couple years (some implementation headers moved from src/dm/ to include/private)  because users wanted access to some internals from a prefix-install (perhaps to create their own derived implementation).
> 
> Is there a good reason not to use 4 for shared headers and #include "mine.h" for unshared (and not intended to be derived from)?