On Nov 23, 2013, at 4:41 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes: > >> This discussion is two vague about what cases you are considering >> >> 1) Dynamic or 2) shared libraries > > I don't understand this distinction. Shared libraries can be opened > with dlopen(). Sure > Static libraries are the issue. Yes > >> a) -prefix install was already made and the plugin install >> installer does not have write access there > > As in, someone else installed PETSc. Yes, this is the most important case I think. > Such as a system administrator on > a Cray. Being able to add external packages to such a build would be a > neat feature, though we probably need to talk to the Cray folks to > ensure that it works properly (changing petscconf.h behind our backs can > break things like this). > >> b) user has old $PETSC_DIR and write access to install location >> (either prefix or not) >> >> Do we plan to support 1 a and b, 2 a and b? What are the >> similarities in the four cases and differences that need to be >> handled. > > If we only do plugins when shared libraries are available, then we just > need plugin paths. That could be an environment variable > PETSC_PLUGIN_PATH containing a list of directories that PetscInitialize > walks through, loading any shared libraries. There could even be a > default global plugin path and a default local (per user) path, so that > typical users don't have to mess with the environment variable, though > if we do that, PETSC_ARCH should appear somewhere so that they don't > collide. Yupe > > It's messier for static libraries because the user needs to link them > explicitly. If we create a petsc-config program (similar to pkg-config, > but I think we need to execute our code), it could walk through the > designated plugin paths to construct a suitable link line that would > include all the plugins. Yupe Or if users used our makefile :-) Barry
