On Feb 16, 2013, at 5:53 PM, Jed Brown <[email protected]> wrote:

On Sat, Feb 16, 2013 at 5:43 PM, Barry Smith <[email protected]> wrote: There might be a petsconf.h petsc-private/petscconfimpl.h petsc-private/petscconfsys.h petsc-private/petscconfdraw.h petsc-privatre/petscconfPACKAGE.h

Okay, but if we took this route, which of these would havePETSC_HAVE_HYPRE? Would it be petscconfksp.h because Hypre is a preconditioning library? Or petscconfdm.h because KSP depends on DM and there is some structured grid stuff in Hypre? Both of those answers would be wrong because of src/vec/vec/impls/hypre/vhyp.c, but I don't see any good way to locally reason about the link failures that would result from defining the macro at the wrong level.

No, as I said in my previous email, it would be in petsc-private/petscconfhypre.h When I wrote petsconfPACKAGE.h I meant this in the sense of PETSc/packages/*.py NOT in the sense of sys, ksp, vec, etc. so there would be a petsconfhypre.py petscconfml.py petscconfsuperlu.py etc etc etc Yes there would also be a petscconfsys.h for things needed in the the sys directory (just so they are not included in snes, ts, etc. No, I am not strongly advocating making this change. Just suggesting it as a natural possibility related to the other recent changes Barry