<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 16, 2013 at 6:00 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5pi">  No, as I said in my previous email, it would be in petsc-private/petscconfhypre.h<br>
<br>
   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<br></div></blockquote>
<div><br></div><div style>Ah, okay.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5pi">
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.<br></div></blockquote><div><br></div><div style>Just splitting petscconfsys.h and petscconfpackages.h might be enough (leaving petscconfbase.h or whatever to contain things like PETSC_USE_DEBUG) would remove dependencies from most source files (that care about neither packages nor sys).</div>
<div style><br></div><div style>If we did this, we should at least put a comment /* #undef PETSC_HAVE_PACKAGE */ for those missing packages, so that we can easily grep to see which header the macro would be defined in.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5pi">
  No, I am not strongly advocating making this change. Just suggesting it as a natural possibility related to the other recent changes</div></blockquote></div><br>Yeah, I'm not convinced it's worth it.</div></div>