<div dir="ltr">On Fri, Feb 15, 2013 at 3:41 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  Since google declared calorically that one cannot do this in C and I refuse to have<br>
#if !defined(PETSCDRAWLGTYPEDEFED)<br>
typedef struct xxx<br>
#define PETSCDRAWLGTYPEDEFED)<br>
#endif<br></blockquote><div><br></div><div>Right, this would be tragic. The safe alternative would be to move only the type declarations to petsc-private/${class}types.h. Then petscpc.h would '#include <petsc-private/dmtypes.h>', but NOT <petscdm.h>. Since petscdm.h also includes dmtypes.h, this would not be user-visible (except that they would need to include petscdm.h to interact with it, but they usually have to include petscdmda.h anyway. (Very few users write truly generic DM code.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
scattered around I put the typedef of PetscDrawLG into petscys.h then small changes were made to the following files<br>
<br>
M include/petsc-private/drawimpl.h<br>
M include/petscdraw.h<br>
M include/petscsys.h<br>
M src/dm/impls/composite/pack.c<br>
M src/dm/impls/da/da1.c<br>
M src/dm/impls/da/da2.c<br>
M src/dm/impls/da/da3.c<br>
M src/dm/impls/da/gr1.c<br>
M src/dm/impls/da/gr2.c<br>
M src/ksp/ksp/interface/eige.c<br>
M src/ksp/ksp/interface/itcreate.c<br>
M src/ksp/ksp/interface/itfunc.c<br>
M src/ksp/ksp/interface/xmon.c<br>
M src/ksp/pc/impls/bjacobi/bjacobi.c<br>
M src/ksp/pc/impls/fieldsplit/fieldsplit.c<br>
M src/ksp/pc/impls/mg/mg.c<br>
M src/ksp/pc/interface/precon.c<br>
M src/mat/impls/aij/mpi/mpiaij.c<br>
M src/mat/impls/aij/seq/aij.c<br>
M src/mat/impls/baij/mpi/mpibaij.c<br>
M src/mat/impls/baij/seq/baij.c<br>
M src/mat/impls/dense/mpi/mpidense.c<br>
M src/mat/impls/dense/seq/dense.c<br>
M src/mat/impls/sbaij/mpi/mpisbaij.c<br>
M src/mat/impls/sbaij/seq/sbaij.c<br>
M src/mat/matfd/fdmatrix.c<br>
M src/snes/impls/fas/fas.c<br>
M src/snes/interface/snes.c<br>
M src/sys/classes/draw/impls/x/ftn-custom/zdrawopenxf.c<br>
M src/sys/classes/draw/interface/ftn-custom/zdrawf.c<br>
M src/sys/classes/draw/interface/ftn-custom/zdrawregf.c<br>
M src/sys/classes/draw/interface/ftn-custom/zdtextf.c<br>
M src/sys/classes/draw/interface/ftn-custom/zdtextvf.c<br>
M src/sys/classes/draw/interface/ftn-custom/zdtrif.c<br>
M src/sys/classes/draw/utils/axis.c<br>
M src/sys/classes/draw/utils/axisc.c<br>
M src/sys/classes/draw/utils/axisimpl.h<br>
M src/sys/classes/draw/utils/dscatter.c<br>
M src/sys/classes/draw/utils/ftn-custom/zaxisf.c<br>
M src/sys/classes/draw/utils/ftn-custom/zzoomf.c<br>
M src/sys/classes/draw/utils/hists.c<br>
M src/sys/classes/draw/utils/lg.c<br>
M src/sys/classes/draw/utils/lgc.c<br>
M src/sys/classes/draw/utils/lgimpl.h<br>
M src/sys/classes/viewer/impls/draw/vdraw.h<br>
M src/ts/interface/ts.c<br>
M src/ts/interface/tseig.c<br>
M src/vec/vec/impls/mpi/pdvec.c<br>
M src/vec/vec/impls/seq/bvec2.c<br>
M src/vec/vec/utils/cmesh.c<br>
<br>
I'm fine with doing this. Is there a better solution?<br></blockquote><div><br></div><div style>I can't think of any utility to having PetscDrawLG declared without also including petscsys.h, but for something like DM (which most of KSP and above does not interact with), I think there is value in putting the declaration in dmtypes.h. Should I experiment with that?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Feb 15, 2013, at 12:38 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
><br>
>   How does one prevent this problem?<br>
><br>
> [ 15%] Building C object CMakeFiles/petsc.dir/src/ksp/pc/impls/is/nn/nn.c.o<br>
> In file included from /Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/bjacobi/bjacobi.c:184:<br>
> /Users/barrysmith/Src/petsc-dev/include/petscdraw.h:283: error: redefinition of typedef ‘PetscDrawLG’<br>
> /Users/barrysmith/Src/petsc-dev/include/petscksp.h:598: error: previous declaration of ‘PetscDrawLG’ was here<br>
><br>
><br>
> On Feb 15, 2013, at 11:28 AM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
><br>
>> 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.<br>

>><br>
>> The normal approach to this is to forward-declare the type, so instead of<br>
>><br>
>> #include <petscao.h> /* includes lots of other stuff */<br>
>> PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*);<br>
>><br>
>> one would write<br>
>><br>
>> typedef struct _p_AO *AO;<br>
>> PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*);<br>
>><br>
>> 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.<br>

>><br>
>> 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.<br>

>><br>
>> It might be nice to get rarely-used stuff like petscdraw.h out of petscsys.h.<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>