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
signature.asc
Description: Digital signature
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
