Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spackcc assumes includes are always in <prefix>/include #7268

Closed
junghans opened this issue Feb 17, 2018 · 1 comment
Closed

spackcc assumes includes are always in <prefix>/include #7268

junghans opened this issue Feb 17, 2018 · 1 comment
Labels
bug Something isn't working external-packages

Comments

@junghans
Copy link
Contributor

Looking at https://github.com/spack/spack/blob/develop/lib/spack/env/cc#L273, spackcc assumes that headers are always in <prefix>/include, which isn't always the case. Especially for external package on Debian/Ubuntu some headers live in e.g. /usr/lib/x86_64-linux-gnu/openmpi/include/.

See #7255 for an example.

v-dobrev added a commit to v-dobrev/spack that referenced this issue Feb 18, 2018
prefix for the mpi.h header. Recommended by @junghans to support some
external configurations, see spack#7268.
junghans pushed a commit that referenced this issue Mar 5, 2018
* [OpenMPI] Add the 'headers' property. This removes some redundant
headers from sub-directories, returned by the default '.headers'
handler.

* [OpenMPI] In the .headers property, add a fallback to search all of
prefix for the mpi.h header. Recommended by @junghans to support some
external configurations, see #7268.
ch741 pushed a commit to ch741/spack that referenced this issue Apr 20, 2018
* [OpenMPI] Add the 'headers' property. This removes some redundant
headers from sub-directories, returned by the default '.headers'
handler.

* [OpenMPI] In the .headers property, add a fallback to search all of
prefix for the mpi.h header. Recommended by @junghans to support some
external configurations, see spack#7268.
@alalazo alalazo added bug Something isn't working external-packages labels Dec 13, 2019
@alalazo
Copy link
Member

alalazo commented Dec 13, 2019

I think this can be understood as reporting 2 issues:

  1. Include directories were always <prefix>/include (solved in Restore computation of include directories #10623)
  2. External packages can't set their paths at a finer grain (tracked in Request ability to specify individual paths (e.g. libdir) in packages.yaml #6472)

As everything here seems to be already solved or tracked elsewhere I'm closing this issue, but feel free to reopen if you think there's something I didn't account for.

@alalazo alalazo closed this as completed Dec 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working external-packages
Projects
None yet
Development

No branches or pull requests

2 participants