[Users] Thoughts on external libraries

[Frank Loeffler]

Hi,

Thanks Erik for the clear and sadly very true state of external libraries.

On Wed, Jun 08, 2016 at 11:22:44AM -0400, Erik Schnetter wrote:
> In the new system, there will be two kinds of external libraries:
> - like MPI or HDF5: an external library must be present that Cactus uses
> - like LORENE: we always build our own (more on this below)

The two types would be "likely to be found as system library someplace",
and "not..." ?

> (6) using a professional package manager that doesn't require root access,
> such as Spack <https://github.com/LLNL/spack>

spack looks promising at a glance, and I didn't have a closer look to
say more. It requires python >2.6 (which would be a change for Cactus),
but that shouldn't really be a big issue.

It is intriguing to try it, but it is also still quite new, which makes
it more likely to fail in 'unusual' situations (like compilers that
require LD_LIBRARY_PATH or such).

I would argue that most users have most libraries installed on most of
the machines anyway, leaving HPC machines out, for which we provide
specific configurations anyway. If they don't, most of the time they
would be able to use a system library if they would just install it
using their native package manager.
I assert that most users would want Cactus to use those libraries, if
present. That means Cactus would need to find them, be able to check if
they are usable, and how they can be used. And that is exactly where we
currently have most of our problems.

That doesn't mean we should change the way we distribute and build
libraries. Your ideas sound very good. They would avoid some of the
kinds of problems we had with external libraries, but only some - except
you propose to have a "let us build, or specify everything by hand"
approach.

Do you know enough of Spack and would be willing to try to use it to
replace the 'build' functionality in some external libraries, and
instead provide a simple script that users would use to 'setup a Cactus
environment' before they would start building configurations?

Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20160608/dc5dcc12/attachment.bin