On Mon, Mar 14, 2011 at 11:00 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
On Mar 14, 2011, at 10:33 AM, Jed Brown wrote:<br>
<br>
> On Mon, Mar 14, 2011 at 16:22, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> 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>
><br>
> How many shared headers are there really?<br>
><br>
><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).<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
</div></div> Then basically almost all the headers belong in include/something because they can and sometimes are used by outsiders. For example access to the guts of any matrix class for implementation in heritence, access to the guts of the gmres data-structure to implement a modified gmres like fgmres, lgmres etc. pc_mg for sure<br>
<br>
So how do we organize private? Same as the source tree? mat/impls/aij/seq etc etc? dump everything in one directory yuck? BTW: if almost all headers go in the header tree then I would argue it becomes a much simplier model if we require ALL headers there.<br>
<br>
<br>
I had resisted doing this but maybe it is the way to go.</blockquote><div><br></div><div>I had resisted suggesting this, but if we are going towards all headers separate, I would suggest an alternative.</div><div><br>
</div><div> 1) Our source, in the source tree, refer to private headers using relative paths or -I</div><div><br></div><div> 2) Install copies all headers under include/private/<sys,ksp,etc>/*</div><div><br></div>
<div> 3) Outside modules refer to the headers by full path</div><div><br></div><div>Then 3) might break if we move things, but they are writing to private interfaces anyway.</div><div><br></div><div> Matt</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888"><br>
Barry<br>
<br>
<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>