From: Julian A. <ju...@tf...> - 2017-06-22 19:48:49
|
Isn't libmesh a component which is heavily dependent on the users needs? So a "one size fits all" RPM is a bit off. In my opinion extending something like [1] (to support more options) would be more appropriate. With Spack you can choose whatever compiler/MPI/PETSc/Trilinos version or version combination YOU want to have. [1] https://github.com/LLNL/spack/blob/develop/var/spack/repos/builtin/packages/libmesh/package.py On Thu, Jun 22, 2017 at 9:21 PM, John Peterson <jwp...@gm...> wrote: > > > On Thu, Jun 22, 2017 at 1:02 PM, Kirk, Benjamin (JSC-EG311) > <ben...@na...> wrote: >> >> Are any of you guys aware of Karl’s project: >> http://openhpc.community/ >> >> A nice yum-based way to kickstart and maintain an HPC environment >> consistent with what a lot of us now like to see. >> >> I’m considering contributing a libmesh build using their framework, but >> was curious if you guys have any experience running it yet. Its on my list >> now but might be a bit... > > > That URL is... interesting. I've been wondering when I would see one of the > new TLDs in real life. > > I haven't clicked around on the site much yet, but it sounds like we would > fit well in the parallel-libs "Component". > > All their stuff appears to be RPM-based? I recently removed a very old > libmesh.spec file in a0a0d81a, maybe that would be a good starting point for > any work on this... > > -- > John > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > -- Julian Andrej Chair of Automatic Control Faculty of Engineering Kiel University Kaiserstrasse 2 | 24143 Kiel | Germany L: Room F-116 T: +49(0)431 880-6121 F: +49(0)431 880-6278 ju...@tf... | http://www.control.tf.uni-kiel.de |