<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 23, 2013 at 8:37 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>We could<br>
<br>
1) keep things the way they are (one could continue to use --ts_type [libraryname:]functionname)<br>
2) pass the flag false to PetscFunctionListFind() for all the XXXSetType() calls so that only string names of registered types can be used for constructors not constructor function names (removing support for using --ts_type [libraryname:]functionname)<br>


3) Strip all support for alternatively search of the executable and libraries for a function name when the requested string name of the type is not found from PetscFunctionListFind() (simplifying unneeded code)<br>
<br>
A) Remove the XXXRegisterDynamic() keeping only XXXRegister() and thus always store the function pointer in the function list, rather than just the string name.<br>
(simplify unneeded code and remove confusing code)</div></blockquote></div><br>What is required for a shared library to implement an XCreate_Y() function? Surely it must (a) be linked to PETSc, thus able to call PETSc functions, and (b) really intend that XCreate_Y be an entry point for this purpose.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>Given these two assumptions, I think it is very reasonable for the shared library to call XRegister("y",XCreate_Y);</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>Now how should we get those shared libraries loaded? Pretty much all plugin or dynamic loading systems that I'm aware of would place it in a search path. Now do we always load all the shared libraries to make sure we have a complete list? That's possible, but the number of loads can be significant. Think of Emacs as an example. It provides two constructs</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>  (require 'feature "filename")</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>  (autoload 'symbol-name "filename" "Documentation string")</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>The first case is analogous to calling PetscDLLibraryOpen(). The second is roughly being provided by the ability to use arbitrary strings, which is not collision-free. I think replacing it with an "autoload" mechanism would be sufficient.</div>

</div>