4 ms·

Pretty sure the make maintainers would be drawn and quartered if they did that. So many things - probably most of the things - would stop building. "Thy build

Pretty sure the make maintainers would be drawn and quartered if they did that. So many things - probably most of the things - would stop building. "Thy build shall be nondeterministic!" is quite a curse to spring on someone :)

t43562 4y ago
These problems come out anyhow when people run the build on a different machine with more or less cores or other issues then the people who are just users of the build have a problem. The worst problems are when nobody realises that a parallelism issue has happened and the binary for some tool on your phone OS gets generated from the old rule instead of the new one and it's just an invisible random bug. Not sure shuffling would help that exact problem of course.
- pixl97 4y ago
  Invisible until it opens up a security exploit, oops that library doesn't have its security flags set.
Arainach 4y ago
If you want to argue this could break legacy products, that's a valid reason why they shouldn't do this. For new development, however, a nondeterministic default ensures no one relies on accidental behavior and is good practice. Golang did this with the order of traversing a map and it's wonderful in practice - if you want to depend on an ordering, sort it yourself.
- blauditore 4y ago
  I disagree: The default should be deterministic but slow, and one should have to go out of their way to e.g. parallelize stuff, at least just enough to understand the risk of it becoming non-deterministic if done wrong.
  - Arainach 4y ago
    Determinism is an implementation that limits your future development. Is a faster sort available? You can't use it. Could you do some of your internal implementation in parallel? You can't do that either, since some customer is relying on exactly how things work today. Backwards compatibility is one of the most important things to do to keep people using your product - if I have to debug and change my code to use version 2 of your product, it's not much more work to switch to a competitor. It's also incredibly difficult to deliver backwards compatibility and requires intentional planning in advance.
  - TeMPOraL 4y ago
    > The default should be deterministic but slow That all but ensures nobody will care then. Performance is, sadly, not a big motivator in most projects.
    - ProblemFactory 4y ago
      Developers will care if they are spending their time waiting for a build. Both could be satisfied with a single-threaded make keeps the standard order to ensure backwards compatibility, but `make -j` that also turns on --shuffle. Which is also backwards compatible, because timing of each target might rearrange them.
licebmi__at__ 4y ago
I would argue that builds would break are already non deterministic, they just appear to be deterministic on "your" machine.

t43562 4y ago

These problems come out anyhow when people run the build on a different machine with more or less cores or other issues then the people who are just users of the build have a problem. The worst problems are when nobody realises that a parallelism issue has happened and the binary for some tool on your phone OS gets generated from the old rule instead of the new one and it's just an invisible random bug. Not sure shuffling would help that exact problem of course.

pixl97 4y ago
Invisible until it opens up a security exploit, oops that library doesn't have its security flags set.

Arainach 4y ago

If you want to argue this could break legacy products, that's a valid reason why they shouldn't do this. For new development, however, a nondeterministic default ensures no one relies on accidental behavior and is good practice. Golang did this with the order of traversing a map and it's wonderful in practice - if you want to depend on an ordering, sort it yourself.

blauditore 4y ago
I disagree: The default should be deterministic but slow, and one should have to go out of their way to e.g. parallelize stuff, at least just enough to understand the risk of it becoming non-deterministic if done wrong.
- Arainach 4y ago
  Determinism is an implementation that limits your future development. Is a faster sort available? You can't use it. Could you do some of your internal implementation in parallel? You can't do that either, since some customer is relying on exactly how things work today. Backwards compatibility is one of the most important things to do to keep people using your product - if I have to debug and change my code to use version 2 of your product, it's not much more work to switch to a competitor. It's also incredibly difficult to deliver backwards compatibility and requires intentional planning in advance.
- TeMPOraL 4y ago
  > The default should be deterministic but slow That all but ensures nobody will care then. Performance is, sadly, not a big motivator in most projects.
  - ProblemFactory 4y ago
    Developers will care if they are spending their time waiting for a build. Both could be satisfied with a single-threaded make keeps the standard order to ensure backwards compatibility, but `make -j` that also turns on --shuffle. Which is also backwards compatible, because timing of each target might rearrange them.

licebmi__at__ 4y ago

I would argue that builds would break are already non deterministic, they just appear to be deterministic on "your" machine.