Telcon: 2015 09 17

Participants

Adds hierarchical module generation!
Haven't checked it out in detail yet, but will be working to merge this into develop

Greg Becker's database branch has been integrated, awaiting a unit test before merging to develop

See becker33-database branch
This adds filesystem caching and avoids traversing an entire spack directory tree.
- Speeds up spack find, other operations.
- Will allow us to track external installations.
Things I added:
- Database is keyed by DAG hashes
  - Re-hashes specs read from the filesystem with its hash to ensure that deps are read in and set up correctly.
- Simplified file locking syntax. Client code can write:
```
with spack.install_db.write_lock():
     # ... do stuff ...
```
- Instead of:
```
with Write_Lock_Instance(spack.install_db.lock, 60):
     # ... do stuff ...
```

Allows simple use system MPI installs in Spack
MPI wrapper support updated -- exposes mpicc, mpicxx, etc. through known variables
- versatile enough to allow packages to build with MPI compilers, regular compilers, or both.
  - Lots of different ways to build with MPI.
- currently a convention but could be modified later to be a contract for virtual deps that provide MPI.

We will be starting a collaboration with Kitware to package ParaView and to build more core functionality.
We'll be hashing out the details and posting as new stuff gets added.

Are all the lock calls around DB access necessary?
Should the DB class just handle its own locking internally?
Todd kind of likes that better than exposing this to client code (e.g., commands)

Some packages need more portability (hard-coded paths, etc.)
Default CMake argument changes
- Default release configuration is not desirable
- RelWithDebInfo optimization level caused some packages to get different answers
- make an easier way to change build type for cmake.
Make default cmake argument support more transparent
- maybe add functions to a custom CMakeExecutable class to manipulate args like CMAKE_BUILD_TYPE
- add a way to show default args more easily.
- Make debug easier, e.g.:
```
    if '+debug' in spec:                                                                  
        cmake.enable_debug() 
```
- more support in cmake executable for cmake-specific features, but try to keep build transparent too
  - Mike likes to be able to grep for cmake arg syntax.

Want to build lots of different compiler flag configurations.
- Parameter studies, etc.
- compare performance and numerics with different compiler flags
Collette wants:
- to pass in a set of "default" flags to be applied generally to a build
- to override these on a per-package basis in a build script.
- to generate different hash versions based on these