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. >
