[petsc-dev] Complaining about PETSC_INTERN

[Barry Smith]

  Fixed. But also added new task https://bitbucket.org/petsc/petsc-dev/issue/36/remove-snes_kspsolve-instead-use-kspsetpre

On Mar 9, 2013, at 10:36 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

> 
> On Mar 8, 2013, at 11:42 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> 
>> 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.
> 
>   That's fine, in addition it should have a specific developer comment indicating why it is extern, because it will be used by other people's implementations  (I had not thought of that case so specifically documenting it is crucial, for "private" functions that normally would be PETSC_INTERN otherwise people will forget and change it wrongly again later.)
>> 
>> 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.
> 
>   We will have some birthing pains as we get the various functions marked correctly and appreciate everyone's help is fixing them. We really HAVE to do this labeling for Windows DLL, so might as well get the benefits on unix at the same time even though it is initially painful.
> 
>   Barry
> 
>> 
>> 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.
>