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

[Jed Brown]

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"

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>

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


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)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110314/73b84b88/attachment.html>