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

[Dmitry Karpeev]

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.