Are we ready to move this "branch" back into petsc-dev? (Aside from the
visibility stuff which is not yet mainstream and won't affect users, I think it
is ready to go).
Barry
On Mar 6, 2013, at 12:10 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> On Tue, Mar 5, 2013 at 11:57 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> This is very nice, much better than before, no confusing macros and
> complicated #if conditions, simpler for the users to understand also.
>
> Does this mean we shouldn't/don't need to/should continue to mark functions
> used in a single file as static?
>
> If we use --with-visibility, unadorned functions behave like PETSC_INTERN
> except that their names will be mangled for clanguage=C++. (The symbols
> aren't visible outside the library so that doesn't matter, except to language
> purists and possibly C++ exception propagation.) I would still prefer to use
> 'static' whenever possible because it makes it easier to determine how much
> code could depend on that function.
>
> I found a few problems so far
>
> 0) Do these really need PETSC_EXTERN? Note that they are not declared
> PETSC_EXTERN when defined, only in snesimpl.h
>
> PETSC_EXTERN PetscErrorCode SNESReset_VI(SNES);
> PETSC_EXTERN PetscErrorCode SNESDestroy_VI(SNES);
> PETSC_EXTERN PetscErrorCode SNESView_VI(SNES,PetscViewer);
> PETSC_EXTERN PetscErrorCode SNESSetFromOptions_VI(SNES);
> PETSC_EXTERN PetscErrorCode SNESSetUp_VI(SNES);
> PETSC_EXTERN_TYPEDEF typedef PetscErrorCode
> (*SNESVIComputeVariableBoundsFunction)(SNES,Vec,Vec);
> PETSC_EXTERN PetscErrorCode
> SNESVISetComputeVariableBounds_VI(SNES,SNESVIComputeVariableBoundsFunction);
> PETSC_EXTERN PetscErrorCode SNESVISetVariableBounds_VI(SNES,Vec,Vec);
> PETSC_EXTERN PetscErrorCode
> SNESDefaultConverged_VI(SNES,PetscInt,PetscReal,PetscReal,PetscReal,SNESConvergedReason*,void*);
>
> They can all become PETSC_INTERN unless we have reason to support plugin
> authors or petscts calling those directly instead of using an interface.
>
>
