#14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Yes, that scheme lacks "stability" against some use cases. Most prominently, adding a new module and importing it, thus turning e.g. `[1 of 3]` into `[2 of 4]`, will have us end up with different uniques and thus different `.o` files and different binaries (and the benefit of reduced `[TH]` compilations is lost for such changes). But the scheme should still solve the most common use cases: * A from-scratch build using the same code and same compiler would result in byte-identical outputs * Resuming a `--make` (`-j`) build after merely touching a file or changing a comment would result in byte-identical outputs * Resuming a `--make` (`-j`) build after changing the code in a module will would result in only the `.o` for that module to change (plus potentially some inlining sites if `-O` is on); `.o` files that were recompiled because of `[TH]` that generate identical `.o` outputs will allow for the identical-.o-file-`[TH]`-avoidance you proposed above The first point will allow us to get byte-reproducible binaries ala Debian's "reproducible builds"; until now due to Unique nondeterminism, this wasn't possible even under guaranteed input control and stopping-the- system-time sandboxes, as Nix does it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14769#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler