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

[Dmitry Karpeev]

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