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

Barry Smith bsmith at mcs.anl.gov
Mon Mar 14 08:08:11 CDT 2011


On Mar 13, 2011, at 11:34 PM, Jed Brown wrote:

> On Mon, Mar 14, 2011 at 05:01, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
> So it is okay to include headers from the source tree other than from
> under $PETSC_DIR/include?
> I thought the subject of this thread expressly banned that.
> 
> That is a style decision that is up to Barry and not something I was trying to address in this latest patch.
> 
> Currently, most things uses <../src/path/to/localinclude.h> but there are a handful of exceptions. I actually prefer using the "localinclude.h" instead of <../src/path/to/localinclude.h> because the former is easier to relocate and recompile (perhaps with a prefix-install where $PETSC_DIR/src is no longer around). In other words, using "localinclude.h" makes stuff in src/pkg/impls/xxx/ appear more like a standalone plugin which I think is a good thing.

    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? Better the simplicity of always using the <../src/path/to/localinclude.h> model.

   Barry

> 
> This email thread is pretty old now, I think there was some misunderstanding of whether the compiler's $PWD affected header resolution (it doesn't) and recall some possible IDE issues but don't know if they were resolved.




More information about the petsc-dev mailing list