diff options
author | Todd Gamblin <tgamblin@llnl.gov> | 2022-01-19 01:04:34 -0800 |
---|---|---|
committer | Todd Gamblin <tgamblin@llnl.gov> | 2022-05-13 10:45:12 -0700 |
commit | e02020c80a8749d82c271913df0d0f9d9e4fac0b (patch) | |
tree | 9636b64488641ee07bf01ac0c1f47d74cbe90ead /.gitignore | |
parent | d900ac2003a39d1789ee62107e3fc2c6e2d8a78f (diff) | |
download | spack-e02020c80a8749d82c271913df0d0f9d9e4fac0b.tar.gz spack-e02020c80a8749d82c271913df0d0f9d9e4fac0b.tar.bz2 spack-e02020c80a8749d82c271913df0d0f9d9e4fac0b.tar.xz spack-e02020c80a8749d82c271913df0d0f9d9e4fac0b.zip |
Include all deps and package content in the `dag_hash()`
For a long time, Spack has used a coarser hash to identify packages
than it likely should. Packages are identified by `dag_hash()`, which
includes only link and run dependencies. Build dependencies are
stripped before hashing, and we have notincluded hashes of build
artifacts or the `package.py` files used to build. This means the
DAG hash actually doesn't represent all the things Spack can build,
and it reduces reproducibility.
We did this because, in the early days, users were (rightly) annoyed
when a new version of CMake, autotools, or some other build dependency
would necessitate a rebuild of their entire stack. Coarsening the hash
avoided this issue and enabled a modicum of stability when only reusing
packages by hash match.
Now that we have `--reuse`, we don't need to be so careful. Users can
avoid unnecessary rebuilds much more easily, and we can add more
provenance to the spec without worrying that frequent hash changes
will cause too many rebuilds.
This commit starts the refactor with the following major change:
- [x] Make `Spec.dag_hash()` include build, run, and link
dependencides and the package hash (it is now equivalent to
`full_hash()`).
It also adds a couple of bugfixes for problems discovered during
the switch:
- [x] Don't add a `package_hash()` in `to_node_dict()` unless
the spec is concrete (fixes breaks on abstract specs)
- [x] Don't add source ids to the package hash for packages without
a known fetch strategy (may mock packages are like this)
- [x] Change how `Spec.patches` is memoized. Using
`llnl.util.lang.memoized` on `Spec` objects causes specs to
be stored in a `dict`, which means they need a hash. But,
`dag_hash()` now includes patch `sha256`'s via the package
hash, which can lead to infinite recursion
Diffstat (limited to '.gitignore')
0 files changed, 0 insertions, 0 deletions