-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deterministic Compilation / Reproducible Builds #405
Comments
I'm afraid this ticket is not going to be very actionable since it falls between Sbt and Scala. In my opinion the output of the compiler should be deterministic regardless of full vs incremental builds. Incremental compilation is not even a concept in the compiler: In the current setup, assuming Sbt is sorting source files prior to sending them to scalac, full builds would be deterministic, but I doubt we can close the ticket in confidence. |
I'll be commenting in the original Discourse thread about reproducibility in Zinc and some of my insights on how to achieve it. It's something I'm focusing on, and others volunteers are too. So far, there's progress. |
I have collected some definitions of "stability" and test cases that show where we do fail to meet the strict definition (same output regardless of source file order or partial compilation of subsets of files). I'm working on fixing those at the moment. |
All scala/scala PRs for this are now merged. |
I'll do some followup work to run the resulting 2.13.x with scalac-stability-check.sh over a few code bases to see if there are any more moles to whack. |
I am really excited about this! We are using scalac with bazel and doing distributed caching (sharing build artifacts across CI runs and also from developer laptops). Cases like these where we had no reproducibility killed the cache (in fact we removed uses of quasi-quotes to improve matters). I really appreciate this work. |
@retronym is this done as of M5, or does work remain for RC1? |
I'll mark it as done for M5. More real world testing might trigger followup work, but all the known problems are solved. |
okay, I'll include it in the M5 release notes |
With reproducibility features: scala/scala-dev#405
With reproducibility features: scala/scala-dev#405
This change makes sure non-repeated annotations are kept in the order they were found in the source code. The motivation is not necessarily to have them in the original order, but to have them in an order that is deterministic across rebuilds (potentially even across different machines), for reasons discussed further in scala#7661 and the corresponding scala/scala-dev#405 I tried adding an 'integration test' in `tests/pos` to be picked up by `IdempotencyCheck.scala`, but unfortunately couldn't reproduce the nondeterminism that way, so didn't end up including it in this commit. I didn't see an obvious place for a 'unit test' of this code, I'd be happy to add one when someone can recommend a good place to put it. This is basically the dotty equivalent of scala/scala@954c5d3 Fixes scala#14743
This change makes sure non-repeated annotations are kept in the order they were found in the source code. The motivation is not necessarily to have them in the original order, but to have them in an order that is deterministic across rebuilds (potentially even across different machines), for reasons discussed further in scala#7661 and the corresponding scala/scala-dev#405 I tried adding an 'integration test' in `tests/pos` to be picked up by `IdempotencyCheck.scala`, but unfortunately couldn't reproduce the nondeterminism that way, so didn't end up including it in this commit. I didn't see an obvious place for a 'unit test' of this code, I'd be happy to add one when someone can recommend a good place to put it. This is basically the dotty equivalent of scala/scala@954c5d3 Fixes scala#14743
This change makes sure non-repeated annotations are kept in the order they were found in the source code. The motivation is not necessarily to have them in the original order, but to have them in an order that is deterministic across rebuilds (potentially even across different machines), for reasons discussed further in scala#7661 and the corresponding scala/scala-dev#405 An 'integration test' `Annotations.scala` was added in `tests/pos` to be picked up by `IdempotencyCheck.scala`, but unfortunately I haven't successfully reproduced the nondeterminism that way. I didn't see an obvious place for a 'unit test' of this code, I'd be happy to add one when someone can recommend a good place to put it. This is basically the dotty equivalent of scala/scala@954c5d3 Fixes scala#14743
This change makes sure non-repeated annotations are kept in the order they were found in the source code. The motivation is not necessarily to have them in the original order, but to have them in an order that is deterministic across rebuilds (potentially even across different machines), for reasons discussed further in scala#7661 and the corresponding scala/scala-dev#405 Some integration tests were added in `tests/pos` to be picked up by `IdempotencyCheck.scala`, but unfortunately I haven't successfully reproduced the nondeterminism that way. I didn't see an obvious place for a 'unit test' of this code, I'd be happy to add one when someone can recommend a good place to put it. This is basically the dotty equivalent of scala/scala@954c5d3 Fixes scala#14743
This change makes sure non-repeated annotations are kept in the order they were found in the source code. The motivation is not necessarily to have them in the original order, but to have them in an order that is deterministic across rebuilds (potentially even across different machines), for reasons discussed further in scala#7661 and the corresponding scala/scala-dev#405 Some integration tests were added in `tests/pos` to be picked up by `IdempotencyCheck.scala`, but unfortunately I haven't successfully reproduced the nondeterminism that way. I didn't see an obvious place for a 'unit test' of this code, I'd be happy to add one when someone can recommend a good place to put it. This is basically the dotty equivalent of scala/scala@954c5d3 Fixes scala#14743
This change makes sure non-repeated annotations are kept in the order they were found in the source code. The motivation is not necessarily to have them in the original order, but to have them in an order that is deterministic across rebuilds (potentially even across different machines), for reasons discussed further in scala#7661 and the corresponding scala/scala-dev#405 Some integration tests were added in `tests/pos` to be picked up by `IdempotencyCheck.scala`, but unfortunately I haven't successfully reproduced the nondeterminism that way. I didn't see an obvious place for a 'unit test' of this code, I'd be happy to add one when someone can recommend a good place to put it. This is basically the dotty equivalent of scala/scala@954c5d3 Fixes scala#14743
This issue is being opened in response to this thread.
I want to have reproducible artifacts output from
scalac
andsbt
so that I can:Because this could be complicated by faffing about too much with a
build.scala
like embedding the current time somewhere, let's assume that not all builds will be reproducible and that doing so might require minimal tweaking.It would be a stretch to require incremental compilation to be reproducible, so what would be sufficient is that any
sbt clean compile
outputs the exact same things.The text was updated successfully, but these errors were encountered: