<div class="gmail_quote">On Mon, Mar 14, 2011 at 16:22, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">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=":1es">What bothers me about this one is that private has no hierarchy and will eventually become cluttered with all kinds of stuff from many different places in PETSc.<br></div></blockquote><div><br></div><div>How many shared headers are there really?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":1es">
<br>
  The reason private was introduced (rather than having all of the private includes directly in the source tree) was sometimes external tools (Lisandros python stuff?) needed access to the files with a --prefix install so it had to go in the include directory. I really like having it in the source (I could give a shit about parts of PETSc source being built independently from the source tree).</div>
</blockquote><div><br></div><div>What about friendliness towards people writing plugins for PETSc. For example, creating a matrix format that is perhaps licensed differently from PETSc and thus not distributable with PETSc itself. So this new format would be compiled somewhere and the shared library dropped in a directory that PETSc inspects in PetscInitialize so it looks to the user like a first-class implementation (and the application need not even be recompiled). Of course this only works if the plugin can be compiled in an environment where it has access to the headers it needs. Those might not be present in a prefix-install.</div>
<div><br></div><div>It would be a shame to distribute your plugin, but not be compilable with the vendor-provided install of PETSc that used prefix like most other libraries.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":1es">  Maybe the private includes should be fixed up to contain (1) what is truly needed in the --prefix directory hence must in the include tree and what (2) belongs somewhere in the source tree.</div></blockquote>
</div><br><div>In my opinion, it is not a matter of whether Lisandro needs them, but rather a decision of which types are "open" in the sense that implementation inheritance is intended versus "closed" in the sense that it is not. This also affects using "static" for implementation functions.</div>