[petsc-dev] installing external packages as shared?

[Eric Chamberland]

On 09/08/2014 06:08 PM, Jed Brown 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.
>
>
> 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).
>

I'm kind of late, but here is a thought:

We link about 350 different executables in 2 flavors (debug and opt), so 
having shared libraries is a major benefit for the linking time of these 
700 little beasts...

So I would plead for having shared libraries for external packages, at 
least when it is possible without too much pain for PETSc developers...

thanks,

Eric