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(). Static libraries are the issue. > a) -prefix install was already made and the plugin install > installer does not have write access there As in, someone else installed PETSc. 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. 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.
pgpxIj6Du3jqz.pgp
Description: PGP signature
