-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Trivial Changes to spack.yaml
Require Rebuild of Some Packages
#12
Comments
Double check if the Spack hash is the same or if it has changed. |
|
Both esmf and access-om3-nuopc have dependencies on parallelio (e.g. https://github.com/spack/spack/blob/c118c7733b9e20f079bb19b84b8ad60cacd2a673/var/spack/repos/builtin/packages/esmf/package.py#L91), so i'd guess its related to parallelio or one of its deps |
Another avenue is the |
Due to chats with spack devs, it might be useful to check the difference between the hashes with |
I don't know what this tells us :-)
|
Lots of noise ... But I have parallelio installed, do a concretise and it decides I need a new one (note
|
Hi @anton-seaice , Can you please try |
https://github.com/spack/spack/releases/tag/v0.22.0:
|
Thanks @harshula - that looks better:
No promises its robust against compiler changes etc ? |
Hi @anton-seaice , I think we've been misusing What kind compiler changes are you concerned about? Spack is meant to identify compiler incompatibilities. |
My memory is that without e.g. it might try and reuse a netcdf using intel 2021.06.0 even if the top level spec is using intel 2021.10.0 For example, I deactivate and try to install netcdf using intel@2021.06.0 and it uses dependencies from 2021.10.0:
(And for completeness, using different compiler might work in that circumstance), so repeat with fortran code + deps: e.g. parallelio with intel 2021.06.0 tries to use netcdf-fortran from intel 2021.10.0 :
|
If Spack considers |
Agreed - but I don't think that's the behavior we want - especially for CD ? |
To convince myself ... I made a new environment where the only difference from the installed environment was to set
|
For example, openmpi (external) is a dependency for our models and it isn't compiled with the same compiler version as we use during our CD. Just to clarify, if your concern about the latency is from the perspective of using In terms of CD, @aidanheerdegen will look at the options and make a decision on what we should use. |
I would like the cake and to be able to eat it too. (i.e. I want the CI to be fast to encourage folks to build using it so that builds are recorded / shareable / for easier reviews:-) |
Hullo peeps, we will need to keep |
Currently, doing trivial modifications to the
spack.yaml
(seen most prominently in #5) require rebuildingparallelio
,esmf
and (therefore)access-om3-nuopc
. This is a bit of a time sink sinceesmf
can take upwards of 1/2 an hour.See the following runs, in which nothing was changed relating to the above packages: https://github.com/ACCESS-NRI/ACCESS-OM3/actions/runs/10987685371/job/30502929361?pr=5#step:8:767, https://github.com/ACCESS-NRI/ACCESS-OM3/actions/runs/10985399681/job/30497188155#step:8:773.
Determine if the current
spack.packages.*.require
statements are not restrictive enough to prevent a rebuild - https://github.com/ACCESS-NRI/ACCESS-OM3/pull/5/files#diff-e8582e74fa156f4e5729a850e52b24f2fde2d815c2c9c360f88c4cf90db851abR10-R20Or maybe it's another problem?
The text was updated successfully, but these errors were encountered: