Repository: spack/spack

Issue:
partial install help, LLVM defaults should change back (default is debug now?)
Re-phrase now that problem is clear.

1. I ran out of space during a `spack install --keep-stage llvm`.  I still have the stage, but `spack install` now deletes any existing stages.  So assuming I get enough free space for a `make install`, will `spack reindex` then show that it has `llvm` installed, or do I need to do something else?

2. LLVM defaults to a debug build.  This is an unacceptable reversion from when there was a `debug` variant.  It likely has ensnared many victims.  It's gotten me twice now.

blame shows @adamjstewart , [it fell in here](https://github.com/LLNL/spack/commit/07aec4366fa8926ee896fdb2f0c5a68dad3267b5#diff-7110bc5b4f5fce0954915e4a3784329c).  Is there any particular reason you deleted the `debug` variant and also made it Debug by default?

I still :heart: you, but this one needs to go back right?  The problem now is that if `debug` variant is reintroduced, that's going to orphan anybody who has currently installed `llvm` without that variant (hashes will change).

- - -

I assume no, but am hoping I just don't know enough.  I **must** recompile this in order to have the expected sizes right?  There is no way to use the existing (but successful) installation without also wasting over 32GB of space?


Discussion:
Short version: if you have the time, I recommend building with ```spack install llvm build_type=Release```

Long version:

> Is there any particular reason you deleted the debug variant and also made it Debug by default?

That PR consolidated the ```build_type``` variant across all instances of ```CMakePackage```. It appears that the default is ```RelWithDebInfo``` rather than Debug (although both may require significant space compared to Release). You can create the Release version with:

```spack spec llvm build_type=Release```

Perhaps in general Release should be the default. 

>  The problem now is that if debug variant is reintroduced, that's going to orphan anybody who has currently installed llvm without that variant (hashes will change)

It is unlikely that variant will be introduced (based on my above point), although possible that debug will no longer be the default. But in general tweaks to the package will invalidate the hash on it. For example even if you add some new variant to control an aspect of the build that is turned off by default, the hash will change. 

As an example, if you use Spack to build llvm with a different setting for build_type, it will be considered a different package (different hash).

> So assuming I get enough free space for a make install, will spack reindex then show that it has llvm installed, or do I need to do something else?

That may work but is not guaranteed to work. Generally Spack will not consider the package installed unless it can successfully install the package itself. Spack should reuse the stage if the last install attempt did not succeed. If it's removing the stage then that's likely a Spack bug, unless you are specifying ```--restage```. That being said the stages are created in the temp filesystem, so if that is getting filled up then the OS may be clearing it out for you. There is a way to specify that Spack stages outside of tmp to avoid this.

Unless ```--keep-prefix``` is specified, Spack will clear out the installation prefix on a fresh invocation of ```spack install```; even if it does, I'd be surprised if it significantly increased build times because the stage is kept and all the build artifacts should be there.

> There is no way to use the existing (but successful) installation without also wasting over 32GB of space?

I'm not sure what you mean here. Are you saying the stage contains 32GB of files and a subset of those are sufficient for a working instance of llvm?
There's a reason it was special-cased before. It makes the package nearly 13 gigabytes instead of a couple of hundred megabytes, someone *needs* to override this for LLVM.

Resolving patch:
diff --git a/lib/spack/spack/build_systems/cmake.py b/lib/spack/spack/build_systems/cmake.py
--- a/lib/spack/spack/build_systems/cmake.py
+++ b/lib/spack/spack/build_systems/cmake.py
@@ -84,7 +84,7 @@ class CMakePackage(PackageBase):
 
     # https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html
     variant('build_type', default='RelWithDebInfo',
-            description='The build type to build',
+            description='CMake build type',
             values=('Debug', 'Release', 'RelWithDebInfo', 'MinSizeRel'))
 
     depends_on('cmake', type='build')
diff --git a/var/spack/repos/builtin/packages/llvm/package.py b/var/spack/repos/builtin/packages/llvm/package.py
--- a/var/spack/repos/builtin/packages/llvm/package.py
+++ b/var/spack/repos/builtin/packages/llvm/package.py
@@ -70,6 +70,9 @@ class Llvm(CMakePackage):
     variant('all_targets', default=True,
             description="Build all supported targets, default targets "
             "<current arch>,NVPTX,AMDGPU,CppBackend")
+    variant('build_type', default='Release',
+            description='CMake build type',
+            values=('Debug', 'Release', 'RelWithDebInfo', 'MinSizeRel'))
 
     # Build dependency
     depends_on('cmake@3.4.3:', type='build')


Test patch: