On Mon, Mar 14, 2011 at 11:00 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > On Mar 14, 2011, at 10:33 AM, Jed Brown wrote: > > > On Mon, Mar 14, 2011 at 16:22, Barry Smith <bsmith at mcs.anl.gov> wrote: > > 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. > > > > How many shared headers are there really? > > > > > > 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). > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > 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 > > 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. > > > I had resisted doing this but maybe it is the way to go. I had resisted suggesting this, but if we are going towards all headers separate, I would suggest an alternative. 1) Our source, in the source tree, refer to private headers using relative paths or -I 2) Install copies all headers under include/private/<sys,ksp,etc>/* 3) Outside modules refer to the headers by full path Then 3) might break if we move things, but they are writing to private interfaces anyway. Matt > > Barry > > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110314/02b1f3f9/attachment.html>
