On 09/08/2014 06:08 PM, Jed Brown wrote:
Barry Smith <[email protected]> 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
