[petsc-dev] reminder never use #include "mylocalinclude.h" in PETSc source

[Matthew Knepley]

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>