<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 15, 2013 at 4:15 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=":9po">Why petsc-private/${class}types.h ? Why in the private directory. It is fine and harmless to include in the public part? plus it allows users to do the same trick and not include all the PETSc stuff in much of their code if we end up doing it in a systematic way?<br>
</div></blockquote><div><br></div><div style>Okay, that's fine. It could also be</div><div style><br></div><div style>include/petsc/${class}types.h</div><div style>include/petsc/private/${class}impl.h</div><div style>
<br></div><div style>if we wanted to reduce the number of files in plain include/. This is mostly relevant when someone installs with --prefix=/usr.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":9po">
<br>
My feeling was that "regular" users could work with a PETSc install where petsc-private wasn't even installed and we just install that so that people can write their own KSP etc etc. With this addition now petsc-private becomes required.</div>
</blockquote></div><br>Anyone who writes a plugin needs petsc-private already, but I get the point.</div></div>