support pkgconfig for mkl#33382
Conversation
|
It doesn't work because it is using the compiler for mkl, and not the compiler for the dependent package. I want to do something like this: But dependent.spec.compiler is a compiler spec and not a compiler. Is it possible to get the compiler from the dependent spec? |
78de164 to
a53e70b
Compare
|
I got rid of the code that tries to automatically add the openmp pkcgconfig. If you are using icx installed manually, then you already need to source the |
d342830 to
927bf72
Compare
|
@adamjstewart: I see you did a force push. I guess that was a rebase? It failed again. I don't think the problem is related to my change. I looked through the logs and see something suspicious below. The build cache emits a lot of messages that look like errors but are not really errors--patchelf failing, 404, ... so I am never sure what the real error is. Do you think below is normal? Should I wait a while, do a rebase and try again? |
|
@scottwittenburg @zackgalbreath can you take a look? |
927bf72 to
f142cc2
Compare
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
|
||
| def setup_dependent_build_environment(self, env, dependent_spec): | ||
| env.set("MKLROOT", self.component_prefix) | ||
| # env.append_path("PKG_CONFIG_PATH", self.component_prefix.lib.pkgconfig) |
There was a problem hiding this comment.
Did something happen during a rebase? This PR seems just to add a commented out line?
There was a problem hiding this comment.
I believe this most recent commit was designed to test whether or not the feature added in this PR was the reason that CI fails 99% of the time.
There was a problem hiding this comment.
@rscohn2 can you uncomment this? It seems like CI is working again.
There was a problem hiding this comment.
It passed when I commented out the line because it did not run any of the tests. The logic that decides when to run tests must be very smart... or broken.
There was a problem hiding this comment.
Does it compute a hash that is not affected by comments?
There was a problem hiding this comment.
Yes, it is very smart. I believe @tgamblin wrote all the logic that goes into computing the hash, he might be able to point to the logic. At a very minimum, we convert to an AST (so comments are stripped), and we manually remove things like docstrings that won't affect the build process.
There was a problem hiding this comment.
You can see the source that affects the hash with:
spack pkg source --canonical intel-oneapi-mkland the hash with
spack pkg hash intel-oneapi-mklit removes directives (like versions that only add metadata), docstrings, comments, and also @when-annotated methods if we can figure out statically that they're irrelevant for a given spec.
There was a problem hiding this comment.
The tests might be the most intuitive way to see what's happening: https://github.com/spack/spack/blob/develop/lib/spack/spack/test/util/package_hash.py#L154-L456
Support pkgconfig by adding the mkl directories to PKG_CONFIG_PATH. Some of the pc files depend on pc files provided by the compiler, so try to add them as well.
@haampie
@rgommers
@adamjstewart