Dear all, This is a failure report using the hashdist method In a HPC environment (linux, infiniband), the petsc compilation fails with ******************************************************************************* 2014/12/15 20:51:22 - INFO: [package:run_job] UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): 2014/12/15 20:51:22 - INFO: [package:run_job] ------------------------------------------------------------------------------- 2014/12/15 20:51:22 - INFO: [package:run_job] Could not find a functional BLAS. Run with --with-blas-lib=<lib> to indicate the library containing BLAS. 2014/12/15 20:51:22 - INFO: [package:run_job] Or --download-fblaslapack=1 to have one automatically downloaded and installed 2014/12/15 20:51:22 - INFO: [package:run_job] *******************************************************************************
10 Ara 2014 tarihinde 18:50 saatinde, Anders Logg <[email protected]> şunları yazdı: > Yes, we likely need a couple of different variants. To begin with, I think > the main focus should be on the kitchen sink variant to get something that is > as close to foolproof as possible for users. > > Note that the current version does not (as promised) build from master. I > made a mistake in how hashdist decides which changesets to use from git. So > the dev version currently builds the stable predefined version. Fix in > progress.. > > -- > Anders > > > Wed Dec 10 2014 at 5:34:42 PM skrev Martin Sandve Alnæs <[email protected]>: > Hashdist is not like any package manager. It doesn't only build packages, but > also manages entire stacks of packages with particular versions of each > living side by side. This allows reproducible stacks if used right, as well > as variations of stacks without rebuilding more than the stack diffs. When > using anything outside of the hashdist stack, reproducibility may be lost. > Pragmatic reasons compel the use of e.g. system compilers, and IMO using > system python as well is best for most linux users. > > I think we need more than one install script. In particular, the kitchen sink > variant which builds e.g. python and numpy etc, and minimal variants that use > system installed python etc. I'd like a variant that doesn't install fenics > so I can install master/next/wip branches myself in another directory. Of > course this means maintenance of stack variants for different platforms, > similar to the dorsal platform scripts. > > Martin > > 10. des. 2014 17:10 skrev "Garth N. Wells" <[email protected]>: > > > On Wed, 10 Dec, 2014 at 11:13 AM, Anders Logg <[email protected]> wrote: > ok, so is there a limited set of Python packages that we could agree on? > > I assume numpy is already included. What about matplotlib? > > A package manager should only install dependencies; user should install other > packages independently, i.e. like Debian/Ubuntu 'recommended' and 'suggested' > packages. > > Garth > > Wed Dec 10 2014 at 12:05:38 PM skrev Johannes Ring <[email protected]>: > On Wed, Dec 10, 2014 at 11:40 AM, Anders Logg <[email protected]> wrote: > > Good points. > > > > iPython seems like a good thing to include. > > > > It would be good to make the system Python libraries visible (but after > > hashdist in the search path) but I don't know how to automatically extract > > the correct path to the system Python libraries. > > > > I think Johannes knows this better than I. > > If we want to use system Python modules, then I don't think we should > build our own Python. > > Johannes > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
