summaryrefslogtreecommitdiff
path: root/.mailmap
diff options
context:
space:
mode:
authorHarmen Stoppels <harmenstoppels@gmail.com>2023-02-16 19:36:22 +0100
committerGitHub <noreply@github.com>2023-02-16 10:36:22 -0800
commit68b711c1ad7157930154fc37f4a912aaf325fbfb (patch)
treef71499a5061dd5f98f3035bc3dcefdf9224a4d44 /.mailmap
parent69369429b6f3cc215a061823c1c7c9aab52b441c (diff)
downloadspack-68b711c1ad7157930154fc37f4a912aaf325fbfb.tar.gz
spack-68b711c1ad7157930154fc37f4a912aaf325fbfb.tar.bz2
spack-68b711c1ad7157930154fc37f4a912aaf325fbfb.tar.xz
spack-68b711c1ad7157930154fc37f4a912aaf325fbfb.zip
view: fix issue with non-contributing specs (#34661)
Specs that did not contribute any files to an env view caused a problem where zip(specs, files grouped by prefix) got "out of sync", causing the wrong merge map to be passed to a package's `add_files_to_view`, which specifically caused an issue where *sometimes* bin/python ended up as a symlink instead of a copy. One such example is kokkos + kokkos-nvcc-wrapper, as the latter package only provides the file bin/nvcc_wrapper, which is also added to view by kokkos, causing kokkos-nvcc-wrapper to contribute 0 files. The test feels a bit contrived, but it captures the problem... pkg a is added first and has 0 files to contribute, pkg b adds a single file, and we check if pkg b receives a merge map (and a does not).
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions