How does one prevent this problem? [ 15%] Building C object CMakeFiles/petsc.dir/src/ksp/pc/impls/is/nn/nn.c.o In file included from /Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/bjacobi/bjacobi.c:184: /Users/barrysmith/Src/petsc-dev/include/petscdraw.h:283: error: redefinition of typedef ?PetscDrawLG? /Users/barrysmith/Src/petsc-dev/include/petscksp.h:598: error: previous declaration of ?PetscDrawLG? was here
On Feb 15, 2013, at 11:28 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > We currently use recursive includes everywhere, so petscdmda.h includes all > of petscao.h just so it can declare DMDAGetAO and similar. Of course most > users of (and implementation files in) DMDA do not reference AO so they don't > need to know about all the AO functions. > > The normal approach to this is to forward-declare the type, so instead of > > #include <petscao.h> /* includes lots of other stuff */ > PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); > > one would write > > typedef struct _p_AO *AO; > PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); > > in which case all three files in PETSc that actually call AO routines would > need to include petscao.h. That is arguably a good thing since it makes the > actual dependencies more explicit, and is recommended by many (mostly C++) > style guidelines. > > Is this something worth considering? I think stuff like petscvec.h and > petscmat.h ends up pretty much always being needed, but petscdm.h is only > used by a handful of files in petscksp and above, for example. > > It might be nice to get rarely-used stuff like petscdraw.h out of petscsys.h.
