[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

[Matthew Knepley]

On Wed, Mar 6, 2013 at 12:57 AM, 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?
>
>   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*);
>
>
>    1) arch-dynamic-cxx-split  (you can guess what these mean, split means
> split libraries) fails with gfortran on Mac. This may have been this way
> for a while, I'm guess it is related to how common blocks in shared
> libraries are not shared by default and nothing to do with recent changes.
>
>    --with-visibility
>
>    2) Fortran auto generated functions are not visible to user code
>
>         Key in Matt's grumbling about sowing and how it should be
> rewritten in Python.  We need to modify bfort to insert visibility macro
> for the functions. Satish, can you look at that?
>
>    3) The -fvisibility=hidden is blindly passed down to all
> --download-packages and will break them all. I fixed MPI.py to crudely
> remove it but we should have it auto-removed for all package builds. Matt,
> can you look at that?


The whole idea of compiler flags is that the compiler understands them. I
think its a bad model to have
flags that might work on one file and not another. That just seems like a
nightmare.

If there really are compiler flags that can break projects, they should be
removed from compilerOptions.py, and
put directly in PETSc/Configure.py and added into the output in Dump().

    Matt


>
>    Barry
>
>
>
> On Mar 5, 2013, at 10:14 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> >
> > On Tue, Mar 5, 2013 at 8:28 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Tue, Mar 5, 2013 at 7:19 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > I'm testing it now.
> >
> > I pushed two minor patches and I'm going through configure now.
> >
> >
> https://bitbucket.org/BarryFSmith/petsc-dev-simp/commits/41ad8d3b80c7a9edf4d80bf2e09f7fb8c0405f2b
> >
> > Okay, ready for testing.
> >
> >
> https://bitbucket.org/BarryFSmith/petsc-dev-simp/commits/8d2ebbb193fb583bccc64015e35640c4e08c3426
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130306/4f62f498/attachment.html>