[petsc-dev] Complaining about PETSC_INTERN

[Jed Brown]

On Fri, Mar 8, 2013 at 11:48 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:

> I was sure this was going to happen...
>
> So now, we have:
>
> PETSC_INTERN PetscErrorCode KSPBuildSolution_Default(KSP,Vec,Vec*);
>
> Then, if PETSC_INTERN endups meaning -fvisibility=hidden, any third
> party code linking with libpetsc.so and implementing a custom KSP
> subtype (like petsc4py does) is no longer able to re-use
> KSPBuildSolution_Default().
>

This is reasonably part of the implementer/plugin API, so I think it should
be renamed to skip the underscore and documented as a developer-level
routine.


> Jed, I very much understand you good intentions with all this, and I
> support your POVs in almost all cases, but this new PETSC_INTERN stuff
> will do harm if people is not really careful when using it.
>
> Other example:
> https://bitbucket.org/dalcinl/petiga/src/49b6285b1380fa6b29d780c7dbe752441b6e9512/src/petigavec.c?at=default#cl-8
> If anyone ever makes these function PETSC_INTERN, PetIGA will likely
> be in trouble.
>

I'm not sure whether it is better to reference these directly like this or
to keep them PETSC_INTERN and have a different (public) API for setting
them. It's extremely fragile to have external projects depending on private
implementation functions like this. It's the same problem we have inside
PETSc where we have derived classes piggy-backing on PCMG, making the logic
is convoluted and brittle and a frequent source of bugs as people try to
change it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130308/366f93dc/attachment.html>