On Mar 5, 2013, at 5:32 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Tue, Mar 5, 2013 at 5:21 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > Please don't make any other changes along this line for right now. I have > to merge my changes (removal/improvement of EXTERN_C_BEGIN/END) everywhere > and test on many combinations of c/c++, dynamic, split libraries and push > before you can make more changes. It is a little hairy. > > Sure, push to a private branch if you want help merging. I have no idea what a branch is, nor even more a private branch is? All I know is that branches in hg cause lots of arguments between Sean, Jed, and Matt. Barry > > On Mar 5, 2013, at 11:09 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > > > > PETSC_INTERN_C is for functions with internal visibility that must use the > > `extern "C"` calling convention. Normally this is any symbol passed to a > > dynamic registration function. > > At times I've wanted to split the PETSc library into two (or more) parts. > The "interface" library, that contains functions users call directly like > KSPSetType(), KSPGMRESSetRestart() and the actual implementations, like > KPSCreate_GMRES(), KSPGMRESSetRestart_GMRES(), these would be loaded > dynamically. Hence I've kept the dynamic registration functions as > PETSC_EXTERN_C, not PETSC_INTERN_C. This "may" be a way to handle different > precisions, complexity in the same application also if we can figure out how > to put each implementation (for different precision, complexity) in a > separate dynamically loaded library and load several at a time (without > symbol conflict). > > Sure, that's an interesting direction. There are still quite a few interface > functions that pass scalars along and I don't see a clean resolution to that > part, but this direction is good to keep in mind. That said, it would be > pretty easy to batch-change PETSC_INTERN_C .* XCreate_Y instances to > PETSC_EXTERN_C. > > We don't have the Windows Problem (need for long-term binary stability when > users abuse private interfaces) so I'm not worried about having a few private > functions that users shouldn't call, but that still have exported symbols. I > put in PETSC_INTERN* because cutting the number of exported symbols in half > seemed substantial enough.
