BTW petscviewer.h included by petscsys.h always includes hdf5.h (when PETSc installed with hdf5) because of hsize_t and hid_t are in the public API of PETSc viewer for hdf5.
We can either have separate petscviewerhdf5.h or we could include just H5public.h and H5Ipublic.h in petscviewer.h to get these beasties defined. I vote for the first but am fine with the second. Barry 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.
