Commit 7e338ad0 authored by Rob Latham's avatar Rob Latham
Browse files

add in some more spack configuration information

parent d1b1c73d
...@@ -29,7 +29,7 @@ CCI's TCP transport), simply build margo: ...@@ -29,7 +29,7 @@ CCI's TCP transport), simply build margo:
spack install margo spack install margo
### Side note: System boost vs. spack boost ### Side note: System packages vs spack packages
The largest dependency for Mercury is the Boost package. If your system The largest dependency for Mercury is the Boost package. If your system
already has Boost, you can teach spack about it and other already has Boost, you can teach spack about it and other
...@@ -37,7 +37,7 @@ already has Boost, you can teach spack about it and other ...@@ -37,7 +37,7 @@ already has Boost, you can teach spack about it and other
Let's say you installed Boost through your distribution (an RPM or DEB package) Let's say you installed Boost through your distribution (an RPM or DEB package)
To inform spack about Boost you e.g. installed from an RPM, you would add it to To inform spack about Boost you e.g. installed from an RPM, you would add it to
`~/.spack/packages.yaml` `~/.spack/<arch>/packages.yaml`
``` ```
packages: packages:
...@@ -48,6 +48,48 @@ packages: ...@@ -48,6 +48,48 @@ packages:
buildable: False buildable: False
``` ```
I have found several other large dependencies that are handled just fine by the
operating system. My `${HOME}/.spack/linux/packages.yaml` file looks like
this:
```
packages:
openssl:
paths:
openssl@1.0.2g: /usr
buildable: False
cmake:
paths:
cmake@3.9.1: /usr
buildable: False
boost:
paths:
boost@1.62: /usr
buildable: False
autoconf:
paths:
autoconf@2.69: /usr
buildable: False
automake:
paths:
automake@1.15.1: /usr
buildable: False
mpich:
paths:
mpich@master: /home/robl/work/soft/mpich
buildable: False
```
You can see that I have flagged several packages as `buildable: False`,
generaly because they are either large packages or have large dependencies. I
tend to work from MPICH's latest version in git, so I have also told spack
about my locally installed MPICH.
These `packages` files live in a platform-specific directory (run `spack arch
-p` to see what platform spack thinks you are on). Pretty helpful for e.g.
Argonne, where a home file system is shared between a linux cluster, a blue
gene, and a Cray. You can describe `packages.py` for each platform.
## Using Mochi Suite ## Using Mochi Suite
One consequence of the spack design (where packages are installed into a prefix One consequence of the spack design (where packages are installed into a prefix
...@@ -73,7 +115,7 @@ Load the margo module into your environment: ...@@ -73,7 +115,7 @@ Load the margo module into your environment:
module add margo-master-gcc-4.7.2-uy4in2w module add margo-master-gcc-4.7.2-uy4in2w
Spack integrages with modules: the integration helps with naming Spack integrages with modules: the integration helps with managing spack's hash-oriented naming convention
spack load margo spack load margo
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment