* Force the recipe for Lua to use the spack compiler.
I'm not sure how the old recipe worked for anyone. The Lua Makefiles set
`CC=gcc` and for my spack environment the first `gcc` found in my `PATH` is
`$SPACK_ROOT/lib/spack/env/gcc`, which is a directory. This caused the build
to fail. My change drops the `-std=gnu99`, but this option doesn't appear
to be required for a sucessful build.
* Preserve the '-std=gnu99' compile option.
Previous package would not install correctly, would throw:
return os.path.join('share', 'lua', '%d.%d' % self.version[:2])
TypeError: %d format: a number is required, not Version
This is a complete rework of the lua package, it also allows the
environment modification classes to handle paths that are not separated
by colons, and uses the support for same in TCL modules as well.
The biggest difference is the handling for lua extension packages, which
now have their paths set correctly by the lua parent package, and have
access to both lua and luarocks as installation tools. See the luaposix
package for what should be required for most lua packages after this.
- This moves var/spack/packages to var/spack/repos/builtin/packages.
- Packages that did not exist in the source branch, or were changed in
develop, were moved into var/spack/repos/builtin/packages as part of
the integration.
Conflicts:
lib/spack/spack/test/unit_install.py
var/spack/repos/builtin/packages/clang/package.py
Package repositories now look like this:
top-level-dir/
repo.yaml
packages/
libelf/
package.py
mpich/
package.py
...
This leaves room at the top level for additional metadata, source,
per-repo configs, indexes, etc., and it makes it easy to see that
something is a spack repo (just look for repo.yaml and packages).