Telcon: 2017 10 19

Participants

Spack concretization is faster
- See: https://github.com/LLNL/spack/pull/5763
- For example: r-rminer (one of the slowest packages to concretize) is down to 5 seconds
How-to added on using Docker with Spack: https://github.com/LLNL/spack/pull/5582
Issue disambiguation page for Spack developers: https://github.com/LLNL/spack/wiki/Issue-Disambiguation
- We have a lot of issues and IMO some of them are redundant (although that can be hard to tell immediately)
If you have a module associated with a compiler entry or an external package, that should work better now
- See: https://github.com/LLNL/spack/pull/5599
- In particular if you need the module to affect LD_LIBRARY_PATH, this PR would help you
- BUT... the flipside is that it's possible for the modules to interfere with Spack's logic for ensuring that Spack-built packages are preferred
- If you find yourself having to add '--with-lib' or '--with-package' statements on account of build failures related to not finding libraries, and you are using compiler/external-package modules, I'm interested to hear about it

Omar: put together a docker setup to run Spack in an isolated environment, was going to look through the docker PR
Omar: working on boost issue (duplicate patches as reported in https://github.com/LLNL/spack/pull/5341#issuecomment-329934008). Started by trying to build boost with "spack build boost" using gcc 5.4.0
Todd: compiler detection, do people build on system where compilers don't rpath runtime libs?
- Patrick: this could be useful because generally we build in one location and install elsewhere