Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,266
    • Issues 4,266
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 394
    • Merge Requests 394
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #8610

Closed
Open
Opened Dec 11, 2013 by EyalLotem@trac-EyalLotem

Rebuild on a definition-based granularity

Currently, GHC rebuilds modules whose mtime suggests they changed, and all dependent modules.

This rebuilds *far* more than is actually necessary due to the change.

For example, if a single definition changed in a module, only that definition needs to be rebuilt, and very few of the definitions in the dependent modules probably depend on it, so only they ought to be rebuilt.

Another example, is temporarily checking out a different branch, and then going back to the master branch. In this case, the mtimes of many modules will change, but the content will remain the same.

If definition-granularity changes were detected, rather than module-granularity, this scenario will rebuild nothing.

This improvement could shorten the development cycle of all Haskell projects significantly, making Haskell a significantly more productive language to use on larger projects.

Trac metadata
Trac field Value
Version 7.6.3
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Assignee
Assign to
⊥
Milestone
⊥
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#8610