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. > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130305/a973d40f/attachment.html>
