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>