3 ms·

I understand why changing comments doesn’t matter, but how do you decide which dependencies don’t need to be rebuilt when certain part of the source code is cha

I understand why changing comments doesn’t matter, but how do you decide which dependencies don’t need to be rebuilt when certain part of the source code is changed?

kevincox 6y ago
The most "proper" way to do this is splitting the result into interface + implementation. For example if you are dynamically linking to a library instead of being given access to the entire library you are given a simplified "signature" which has the minimal amount of info required to linking. This interface would change when you add or remove a function, but not when a function body changes. The example was given for linking but this can be done for many steps of the build process.
Ericson2314 6y ago
Nix does this simply and stupidly --- if you can observ it, it's part of the cache key. This is wonderful because it's totally sound. All efficiency methods (basically, hiding things, as the other comment says) is left to the build plan itself. Switching to Nix for batch jobs is switching from DOS to an OS with actual process isolation. A complete paradigm shift.
- sterlind 6y ago
  It does still require trust, though. You can lie about the contents since the hash only covers the build inputs, so someone could break the sandboxing. Of course, since builds are reproducible you can catch this if you build it yourself and compare the actual content-hashes.
  - Ericson2314 6y ago
    I would say the trust issues with build remotes and substitutors are fairly independent of the caching policy? The caching model is about when the drv changes ((drv, output) is the cache key, basically), the trust model is one one can download something to avoiding build to fill in the value for the new cache key. Note also that with the new floating content-addressed derivations, the trust stuff is much easier to think about.

3 ms·

I understand why changing comments doesn’t matter, but how do you decide which dependencies don’t need to be rebuilt when certain part of the source code is cha

by teacpde 6y ago

I understand why changing comments doesn’t matter, but how do you decide which dependencies don’t need to be rebuilt when certain part of the source code is changed?

kevincox 6y ago
The most "proper" way to do this is splitting the result into interface + implementation. For example if you are dynamically linking to a library instead of being given access to the entire library you are given a simplified "signature" which has the minimal amount of info required to linking. This interface would change when you add or remove a function, but not when a function body changes. The example was given for linking but this can be done for many steps of the build process.
Ericson2314 6y ago
Nix does this simply and stupidly --- if you can observ it, it's part of the cache key. This is wonderful because it's totally sound. All efficiency methods (basically, hiding things, as the other comment says) is left to the build plan itself. Switching to Nix for batch jobs is switching from DOS to an OS with actual process isolation. A complete paradigm shift.
- sterlind 6y ago
  It does still require trust, though. You can lie about the contents since the hash only covers the build inputs, so someone could break the sandboxing. Of course, since builds are reproducible you can catch this if you build it yourself and compare the actual content-hashes.
  - Ericson2314 6y ago
    I would say the trust issues with build remotes and substitutors are fairly independent of the caching policy? The caching model is about when the drv changes ((drv, output) is the cache key, basically), the trust model is one one can download something to avoiding build to fill in the value for the new cache key. Note also that with the new floating content-addressed derivations, the trust stuff is much easier to think about.