[petsc-dev] installing external packages as shared?

[Barry Smith]

On Sep 8, 2014, at 5:08 PM, Jed Brown <jed at jedbrown.org> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>   When should we install external packages as shared, currently if
>>   —with-PACKAGENAME-shared is set or if —with-shared-libraries is set
>>   we do it for some packages (like MPICH). Other packages, such as
>>   hypre don’t build properly as shared. So my question is if
>>   —with-shared-libraries is set should be build the packages that can
>>   be built with shared libraries or should we build static unless
>>   specifically requested for that package?
> 
> What does --download intend to be?
> 
> 1. A general-purpose package manager bundled with PETSc.  Installs
> packages in a way that makes sense on the user's computer and is
> fully-functional independent of PETSc.
> 
> 2. A quick and dirty way of installing dependencies to be used by PETSc.
> Not intended to be used independent from PETSc (though it might work).
> Package manager functionality like upgrades and uninstall are not
> provided.

  3) A simple and dependable way to install many dependencies of PETSc :-) and other HPC numerical software libraries

   In my mind the —prefix should (if used) generally be a path unique to a particular build of PETSc (that can be removed with a single rm) and NOT standard locations like /usr/local where they get mixed up with packages installed in other ways. We could even add a warning :-), that no one will read.

  Barry

> 
> 
> If 1, then packages should be installed in the way that makes most sense
> on the target computer, so shared libraries in most cases where it is
> possible.  This is a busy space with lots of competitors that rarely
> play well together.  If 2, then it's okay to always build static
> libraries (with -fPIC) and link them into libpetsc.so (when libpetsc.so
> is dynamic).