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.
This can be automated in various ways. An install (of any kind) could dump the headers from every descendant of src/ into the corresponding include/private/ subdir, or maybe even include/src/. Then just include it as <mat/impls/aij/seq/aij.h>? Maybe the headers can even go into $PETSC_DIR/$PETSC_ARCH/include/... for non-prefix installs, although that would mean replicating a lot of headers, but disk space is cheap. Dmitry. > > > ? I had resisted doing this but maybe it is the way to go. > > ? Barry > > > > >
