Make sure you have downloaded Spack and added it to your path. The easiest way to do this is often (depending on your SHELL):
> source spack/share/spack/setup-env.sh
To get the most up-to-date version of the SST Spack packages, after downloading the sst-spack GitHub repository, you simply need to run
> spack repo add sst-spack/sst
To validate that Spack now sees the repo with the SST packages, run:
> spack repo list
This should now list your newly downloaded Spack repo. You can display information about how to install the individual packages with, e.g.:
> spack info sst-core
This will print all the information about variants and dependencies of the package. For detailed instructions on how to use Spack, see the Owner's Manual.
A basic installation of a package is done as:
> spack install sst-core +pdes-mpi
which tells Spack to install the core with PDES support using MPI.
For downstream packages like sst-elements, sst-core and all dependencies will be automatically installed.
We can visualize this with either spack spec or spack graph, e.g.
> spack spec sst-elements +pin +hybridsim
Input spec
--------------------------------
sst-elements+hybridsim+pin
Concretized
--------------------------------
sst-elements@master%[email protected]~dramsim2~goblin~hbm+hybridsim~nvdimmsim+pin~ramulator arch=linux-centos7-haswell
^[email protected]%[email protected] arch=linux-centos7-haswell
^[email protected]%[email protected] arch=linux-centos7-haswell
^[email protected]%[email protected] arch=linux-centos7-haswell
^[email protected]%[email protected] patches=e266e00e3777feb1d9b3691f6a5a88d1d99c5aa0e0811fcf5461d55e0ac4a7bd arch=linux-centos7-haswell
^[email protected]%[email protected] arch=linux-centos7-haswell
^[email protected]%[email protected] arch=linux-centos7-haswell
^[email protected]%[email protected] arch=linux-centos7-haswell
^[email protected]%[email protected]+bz2+ctypes+dbm~debug+libxml2+lzma~nis~optimizations+pic+pyexpat+pythoncmd+readline+shared+sqlite3+ssl~tix~tkinter~ucs4~uuid+zlib arch=linux-centos7-haswell
^sst-core@master%[email protected]~hdf5+pdes-mpi~zlib~zoltan arch=linux-centos7-haswell
^[email protected]%[email protected]~cuda+cxx_exceptions fabrics=none ~java~legacylaunchers~memchecker~pmi schedulers=none ~sqlite3~thread_multiple+vt arch=linux-centos7-haswell
This shows what will be installed along with the specification of all the dependencies. If any of the dependencies are missing, Spack will download and install them. Note here that the default compiler for this Spack is GCC 7.4. If we wish to use a different compiler, we can specify it as, e.g:
> spack install sst-elements +pin +hybridsim %[email protected]
To make sure your desired compiler is known to Spack, you can check:
> spack compiler list
==> Available compilers
-- clang centos7-x86_64 -----------------------------------------
[email protected]
-- gcc centos7-x86_64 -------------------------------------------
[email protected] [email protected]
All compilers in the path are usually located by running spack compiler find and automatically added.
Spack has historically been much more suited to deployment of mature packages than active testing or developing. However, recent features have improved support for development. Future releases are likely to make this even easier and incorporate Git integration.
A common pattern in testing is validating a successful build of feature branches.
Spack provides the dev-build feature for building and installing from a custom source folder.
For example:
> git clone [email protected]:sstsimulator/sst-core.git -b devel src
> spack dev-build -d src sst-core@devel +pdes-mpi
is equivalent to just running
> spack install sst-core@devel +pdes-mpi
For validating a complete build of the "core" packages (sst-core, sst-elements, sst-macro) with any combination of branches, one can simply run:
> git clone [email protected]:sstsimulator/sst-core.git -b feature-core sst-core-src
> git clone [email protected]:sstsimulator/sst-macro.git -b devel sst-macro-src
> git clone [email protected]:sstsimulator/sst-elements.git -b feature-elems sst-elements-src
> spack dev-build -d sst-core-src sst-core@devel core-variants... %compiler
> spack dev-build -d sst-macro-src sst-macro@devel macro-variants... ^sst-core@devel core-variants... %compiler
> spack dev-build -d sst-elements-src sst-elements@devel elem-variants... ^sst-core@devel core-variants... %compiler
Here %compiler is a spec like [email protected].
core-variants... is the desired sst-core spec like +pdes-mpi +zoltan.
Note the the ^ syntax used here to ensure that sst-elements and sst-macro depend on a precise variant of sst-core.
For example:
> spack dev-build -d sst-macro-src sst-macro@devel +otf2 +core ^sst-core+pdes-mpi+zoltan
Because we are doing feature branch testing, we use @devel to build the branches as-if they were the devel branch.
The above commands will do a full build and install of the packages. If doing development, you may wish to merely set up a build environment. This allows you to modify the source and re-build. In this case, you can stop after configuring:
> spack dev-build -d sst-core-src -u configure sst-core@devel +otf2 +core ^sst-core+pdes-mpi+zoltan
This sets up a development environment for you in sst-core-src, which you can use (Bash example shown):
> cd sst-core-src
> source spack-build-env.txt
> cd spack-build
> make
Before sourcing the Spack development environment, you may wish to save your current environment:
> declare -px > myenv.sh
When done with Spack, you can then restore your original environment:
source myenv.sh
Spack assumes nothing is available on your system, including even basic utilities like Perl and M4.
This leads to Spack "bootstrapping" for each new install (and each compiler!) many, many packages.
It is recommended to set up a packages.yaml file in a $HOME/.spack folder that identifies your default local packages.
Below is an example file with the most important packages for efficient SST development:
packages:
zlib:
paths:
zlib: /usr
buildable: False
libtool:
paths:
[email protected]: /opt/local
buildable: False
cmake:
paths:
[email protected]: /opt/local
buildable: False
pkg-config:
paths:
pkg-config: /opt/local
m4:
paths:
m4: /usr
buildable: False
numactl:
paths:
[email protected]: /opt/local
buildable: False
hwloc:
paths:
[email protected]: /usr
[email protected]: /opt/local
buildable: False
python:
paths:
[email protected]: /usr
[email protected]: /opt/local
variants: +shared
buildable: False
The paths would need to be updated for your system.
If you never want Spack to re-build a library (which is often the case for C libraries like hwloc),
you need the buildable: False entry.
In most cases a single version suffices, but you may need multiple versions to resolve conflicts (as was the caes here for Python and hwloc).
In other cases, you may need to identify the Spack variants supported by your local installation.
In this case, we had to inform Spack that our Python has shared libraries.
With the packages.yaml, our Spack dependency graph for spack graph sst-core +pdes-mpi is:
o sst-core
|\
| o openmpi
| |\
| | |\
| o | | zlib
| / /
o | | python
/ /
o | numactl
/
o hwloc
In this case, the only dependency Spack will build is openmpi (recommended due to the compiler dependence).
Without the packages.yaml, a huge dependency graph would be built:
o sst-core
|\
o | python
|\ \
| |\ \
| | |\ \
| | | |\ \
| | | | |\ \
| | | | | |\ \
| | | | | | |\ \
| | | | | | | |\ \
| | | | | | | | |\ \
| | | | | | | | | |\ \
| | | | | | | | | | |\ \
| | o | | | | | | | | | | sqlite
| |/| | | | | | | | | | |
|/| | | | | | | | | | | |
| | |/ / / / / / / / / /
| | | | o | | | | | | | openssl
| |_|_|/| | | | | | | |
|/| | | | | | | | | | |
| | | | | | | | | | | o openmpi
| |_|_|_|_|_|_|_|_|_|/|
|/| | | | | | | | | | |
| | | | | | | | | | | |\
| | | | | | | | | | | | o hwloc
| | | | |_|_|_|_|_|_|_|/|
| | | |/| | | | | | | |/|
| | | | | | | | | | | | |\
| | | | | | | o | | | | | | gettext
| | |_|_|_|_|/| | | | | | |
| |/| | | | |/| | | | | | |
| | | | | |/| | | | | | | |
| | | | | | | |\ \ \ \ \ \ \
| | | | | | | | |\ \ \ \ \ \ \
| | | | | | | | | |_|_|_|_|/ /
| | | | | | | | |/| | | | | |
| | | | | | | | | | |/ / / /
| | | | | | | | | |/| | | |
| | | | | | | | o | | | | | libxml2
| |_|_|_|_|_|_|/| | | | | |
|/| |_|_|_|_|_|/| | | | | |
| |/| | |_|_|_|/| | | | | |
| | | |/| | | | | | | | | |
o | | | | | | | | | | | | | zlib
/ / / / / / / / / / / / /
o | | | | | | | | | | | | xz
/ / / / / / / / / / / /
| | | | | | | | | | | o libpciaccess
| | |_|_|_|_|_|_|_|_|/|
| |/| | | | | | | | | |
| | | | | | | | | | | |\
| | | | | | | | | | | o | util-macros
| | | | | | | | | | | /
| | | | | o | | | | | | tar
| | | | | |/ / / / / /
| | | | | | | | | o | numactl
| | | | | | | | | |\|
| | | | | | | | | |\ \
| | | | | | | | | | |\ \
| | | | | | | | | | o | | automake
| | | |_|_|_|_|_|_|/| | |
| | |/| | | | | | | | | |
| | | | | | | | | | |/ /
| | | | | | | | | | o | autoconf
| | | |_|_|_|_|_|_|/| |
| | |/| | | | | | |/ /
| | o | | | | | | | | perl
| | | |_|_|_|/ / / /
| | |/| | | | | | |
| | o | | | | | | | gdbm
| |/ / / / / / / /
|/| | | | | | | |
o | | | | | | | | readline
| |/ / / / / / /
|/| | | | | | |
o | | | | | | | ncurses
|/ / / / / / /
o | | | | | | pkgconf
/ / / / / /
| | | | | o libtool
| | | | |/
| | | | o m4
| | | | o libsigsegv
| | | |
| | o | bzip2
| | o | diffutils
| |/ /
| o | libiconv
| /
o | libffi
/
o expat
o libbsd