<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 5:21 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2tj">  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.<br>
</div></blockquote><div><br></div><div style>Sure, push to a private branch if you want help merging.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":2tj"><div class="im">
On Mar 5, 2013, at 11:09 AM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
><br>
> 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.<br>
<br>
</div>    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).</div>
</blockquote></div><br>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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>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.</div>
</div>