On Mon, Mar 14, 2011 at 10:22 AM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > 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.
So, my understanding is that the headers in the include/ tree is only what's needed by the applications (those need include/) and external tools (additionally need the private headers include/private/). The headers in the src/ tree are for the interoperability between different impls. These src/ tree private headers can be addressed either relative to include/ (via ../src/mat/impls/aij/seq/aij.h) or relative to the including file (../seq/aih.h), and that choice is up to the particular developer, although Barry strongly prefers the former? Dmitry. > > > ? 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)? > >
