On Mon, Mar 14, 2011 at 10:33 AM, Jed Brown <jed at 59a2.org> 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.
"open" headers can be included, even if they are in the src/ tree, though. That might make more sense, because then the path to the header indicates what's being inherited from. Sticking them in include/private requires a disambiguating name. Dmitry.
