Repository: spack/spack

Issue:
suite-sparse+tbb cannot find include 
I've been trying to patch this myself but I can't figure out what's going on, and honestly don't know how to debug `spack` very well (I literally raise exceptions and print out `__dict__` half the time, is there a way for me to open up `pdb` or something somehow?)

The issue: `suite-sparse+tbb`:

```
../Source/spqr_parallel.cpp:10:37: fatal error: tbb/task_scheduler_init.h: No such file or directory
```

The file definitely exists, but I can't quite figure out how to include it for this package.

```
 98         if 'tbb' in spec:
 99             make_args.extend([
100                 'SPQR_CONFIG=-DHAVE_TBB',
101                 'TBB=-L%s -ltbb' % spec['tbb'].prefix.lib,
102             ])```
```

I tried to add just a straight `'-I%s' % spec['tbb'].prefix.include` as well as instead setting `'TBB_PATH=%s' % spec['tbb'].prefix`, but it's clearly not the right way to do this.

Unrelated, I'm noticing a bunch of cuda stuff.  I was gonna tinker with this a bit since I'm here, but should that go in a different PR (assuming I can fix the include thing)?
Suitesparse tbb fix
Fixes #4160


Discussion:
`-I` are added automatically in compiler wrappers. I had issues with TBB in suite-sparse before, then at some point it was fixed and then in later releases it got broken again. I would contact developers, see http://faculty.cse.tamu.edu/davis/suitesparse.html for e-mail address.

for example

os.environ['SLEPC_DIR'] = os.getcwd()

> On 8 May 2017, at 22:06, Stephen McDowell <notifications@github.com> wrote:
> 
> Ok sounds good. As a corollary, where in the spack setup process can I set environment variables? Like just point me to a package to refer to our docs?
> 
> I've been spinning their docs and they seem to need TBB_PATH. I want to provide them more information if possible
> 
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub <https://github.com/LLNL/spack/issues/4160#issuecomment-299975493>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHpvfjZXxZ8LmTJQ-wc48MGeuPmGb5Qrks5r33WwgaJpZM4NUa61>.
> 


> `-I` are added automatically in compiler wrappers

Not according to by `spack-build`...the referencing PR is all I actually needed to fix this, I feel quite strongly about leaving the `NOTE` in there.  There seems to be something bigger going on with the staging environment, and if that patch stops being applicable this package is gonna need some love.  Until then, this seems to work :smile:
superfail. they unflagged me, but since it isn't [showing up](https://travis-ci.org/LLNL/spack/pull_requests) _again_ i think i got flagged again
I think I finally know why `travis` was getting upset with me.  The first build I ever did via a PR was _before_ I changed my username.  I had never actually created an account with them, but I just did by signing in through GitHub and it was finally able to run.  It showed in the previous flagging incident my original username.

Anyway, it might be better to hold off merging this.  It's open and available, if people have trouble they can `spack edit suite-sparse` and add this one-liner, but I agree...this _should have_ already been in the build environment so it seems like something bigger has been broken and this is a side-effect.
Took a look at the compiler wrappers. We are adding `-I/path/to/include` flags for all dependencies in `SPACK_DEPENDENCIES`. If you run:
```
$ spack env suite-sparse+tbb | grep SPACK_DEPENDENCIES | grep tbb
SPACK_DEPENDENCIES=/home/ajstewart/spack/opt/spack/linux-fedora25-x86_64/gcc-6.2.1/metis-5.1.0-rt5umyrihxwgfvzvcn5qnxqpdx5wkufs:/home/ajstewart/spack/opt/spack/linux-fedora25-x86_64/gcc-6.2.1/cmake-3.8.0-sea3xe4rmklrjt274dq4u4qsc5nxfg5y:/home/ajstewart/spack/opt/spack/linux-fedora25-x86_64/gcc-6.2.1/ncurses-6.0-ybsic3iw357ybnc3wr6zpvfo2t25zzxk:/home/ajstewart/spack/opt/spack/linux-fedora25-x86_64/gcc-6.2.1/pkg-config-0.29.2-c24x5hrxzzknguliukyfwazn3qzbgoms:/home/ajstewart/spack/opt/spack/linux-fedora25-x86_64/gcc-6.2.1/openssl-1.0.2k-n3qhtufv2e5slka7i23gvcw5kegi25vf:/home/ajstewart/spack/opt/spack/linux-fedora25-x86_64/gcc-6.2.1/zlib-1.2.11-r2vrtgrpvsgryvtexeqxh4xehmddiflw:/home/ajstewart/spack/opt/spack/linux-fedora25-x86_64/gcc-6.2.1/openblas-0.2.19-yodax7bzhlbhqn4w5wgvfgh65j6pqdi3:/home/ajstewart/spack/opt/spack/linux-fedora25-x86_64/gcc-6.2.1/tbb-2017.5-mbdxjq4xrp74nzzag7dwotancnxamtav
```
you'll see that `tbb` is in their like it should be. Perhaps the build script is using a system compiler instead of calling the compiler wrapper?
> Perhaps the build script is using a system compiler instead of calling the compiler wrapper?

:+1: 

I don't know how it's possible since we have
```
'CC=%s' % self.compiler.cc,
'CXX=%s' % self.compiler.cxx,
'F77=%s' % self.compiler.f77,
```
maybe they disregard this somehow?...
> maybe they disregard this somehow?...

Wouldn't be the first time I've seen that 😆 

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/suite-sparse/package.py b/var/spack/repos/builtin/packages/suite-sparse/package.py
--- a/var/spack/repos/builtin/packages/suite-sparse/package.py
+++ b/var/spack/repos/builtin/packages/suite-sparse/package.py
@@ -62,12 +62,11 @@ def install(self, spec, prefix):
 
         make_args = ['INSTALL=%s' % prefix]
 
-        # inject Spack compiler wrappers
         make_args.extend([
+            # By default, the Makefile uses the Intel compilers if
+            # they are found. This flag disables this behavior,
+            # forcing it to use Spack's compiler wrappers.
             'AUTOCC=no',
-            'CC=%s' % self.compiler.cc,
-            'CXX=%s' % self.compiler.cxx,
-            'F77=%s' % self.compiler.f77,
             # CUDA=no does NOT disable cuda, it only disables internal search
             # for CUDA_PATH. If in addition the latter is empty, then CUDA is
             # completely disabled. See


Test patch: