Things needed to convert the world to using spack for development

Here's my wishlist of features needed to convert everyone to using spack for development:

• More clarity on spack develop-- do I specify the spec/variants in the develop section or in the packages section? It seems to me that I would want to specify variants and such in the packages: section, and then just list the paths in develop.
• I'd like a way to control where my develop build directories are placed within a build system that supports that workflow. This is needed to support git workflows where I have multiple builds out of the same directory, some of which may be based off of develop and therefore will have the same hash, and to avoid conflicts.
• I don't like that I need to modify my internal spack install path to a ridiculously long string in order to build packages that are compatible with a build cache. Ideally I'd like some middle ground or workaround so that any user using spack could contribute packages to a build cache.
• I don't like that spack uses compiler wrappers. It's awkward that I have to invoke a separate shell in order to run "make" myself. Also, I've worked on many cmake projects that use dynamic compilation, and these projects all embed the compiler used by cmake into the binaries or scripts. Forcing everyone to use the cmake compilers will break these codes.
• buildcache symlinks need to be relocated as well, when it makes sense to do so.
• Iterative builds for things for cmake/autoconf/make need to be supported. Cmake is done, make should be done as well, what about autoconf?
• Some of our software build systems use our cluster resources in order to build things faster. How can spack take advantage of this?
• Installing software from a spack binary package needs to be faster. Maybe spack could cache the binary/text locations where it needs to do replacements?
• When installing binary packages from a spack mirror, it's important that the user be provided with a prompt to "trust packages from this resource?" option. It'd also be nice if there was a command line option to do the equivalent of "always-trust" when using build caches.
• When pushing a package to a build cache, I'd also like to push the build dependencies needed for building the package. These packages get installed when I use the cache, so if I don't push them I end up recompiling a whole bunch of stuff from source, which can be slow.
• I'd like a command to populate my local environment with just the external packages/compilers that I'm currently using from my global config. I need to have that stuff in there when I'm sending my spack.yaml to someone else, but by default spack external find and spack compiler find add everything. This adds a ton of noise to the spack.yaml file and makes it hard to figure out what's going on.
• When specifying develop in an environment, it would be nice if I could tell spack to checkout a specific revision from my source code repository.
• As a developer, I need a way to specify arbitrary flags to cmake/autoconf/make without modifying the spack package. I need this because I can't be changing the spack package every time I make a small change and need to test it.

---

How I imagine this working, for common developers.

1. You get a .yaml file that sets up a common build environment for your team. Maybe samples are even checked into the source code of your project. This yaml file is copied over into a directory and an environment is created.
2. You run spack install and your project builds with all of it's dependencies in spack, grabbing the things you aren't actively developing from a build cache that has been preconfigured in your .yaml file. This takes no more than an extra 10% of the build time it would take if you were using a prefix-based install system.
3. You start hacking on a piece of the code, and get one part of it working, using something like a spack build <package> command to invoke the makefile of your subpackages.
4. You run tests as normal on the binaries, as you get binaries installed for free with this method.
5. When you're satisfied you check in.
6. When you're ready to make a new release, you comment out the develop, spack install again, build a binary of your code, and push it to an appropriate build cache.

All this depends on :

• binary caches working and working well.
• You'll need to be able to specify more in your .yaml file than you currently can, like repositories, build_directories, git commits and/or branches, svn revisions...
• it also depends on having a spack build <package> or equivalent command. This command should build the current package and any of it's dependents if necessary.
• it needs to be easy to make the .yaml files that people will be using
• it has to be easy to set up the build caches.

Open questions from developers:

• Is spack build <package> a good idea? Are you sure we don't just want to type make locally?
  • If you have access to the build directories, I think running "make" inside those would be fine. I'm more concerned about cases where I would want to build the package and the surrounding dependencies. What I don't what to do is have to "cd" to each directory and build there.
• How do you construct spack friendly build systems?
  • cmake seems pretty friendly already. Autoconf might be a bigger problem...
  • If we push cmake on people, then we can also always modify BLT to make it easier to use with spack, allowing things like undoing the spack compiler wrappers maybe?
• How do you write spack packages that will work well for developers?
  • I think developers are going to need a way to specify arbitrary make/autoconf/cmake flags to the package, in the same way that people currently do cflags for a package.
  • Code packages can also have private repositories with their own custom packages that never go to the public github, if they want to test out new features. A team can maintain their own package if they so wish, so long as the team has a directory where they all see.
  • An alternate package with extra private variants can also be checked into git, and the provided .yaml files (also checked in) can point to that package that's in the source code.
• What if I'm hacking on a low level library and I just want to make sure the library builds before I try the full integration?
  • Typing "make" within a build directory should work, as should something like spack build . or equivalent.
• Will developers tolerate spack build <package> instead of make? People complain about typing 1 extra character and you added far more.
  • I argue that spack build <package> is easier than (cd pkgA; make) && (cd pkgB; make)