Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,349
    • Issues 5,349
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 575
    • Merge requests 575
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #10827
Closed
Open
Issue created Sep 02, 2015 by Edward Z. Yang@ezyangDeveloper

GHC (especially ghci) should support multiple home units with separate DynFlags

Stack and other tools are attempting to make the user-experience of developing multiple packages simultaneously better. Thus, if you have source packages p, q and r (which all depend on them), stack build builds all of them. They are quite interested in support stack ghci but there are problems: https://github.com/commercialhaskell/stack/issues/665


edit: These are Edward's original technical notes. The new plan is in https://gitlab.haskell.org/ghc/ghc/-/wikis/Multi-Session-GHC-API . Both his 1) and 2) are solved dispensing with a notion of a single "home package", and instead having multiple, with their own flags (including src dirs) etc.

The essence of the problem is twofold:

  1. If you ask GHCi to interpret modules from multiple packages (e.g. by having multiple source directories), GHCi currently only knows how to put all of them into the same home package. This will fail if two packages have a module with the same name; also, modules in the other packages will always see modules (even if they're supposed to be hidden).
  2. A GHCi session only has one global set of dynamic flags, but each package may be compiled with its own set of DynFlags (e.g. package global LANGUAGE pragmas). This means the "default DynFlags" needs to be varied between packages.

It's not too obvious to me how to fix (1) (at least, you'd have to make the HPT support sets of HomeModInfos from multiple packages), but (2) seems tractable: since we already track DynFlags on a per-module basis, we just have to arrange for a "package" level DynFlag to be applied to the correct ModSummarys.

Similar functionality would be useful for Backpack.

Trac metadata
Trac field Value
Version 7.11
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component GHC API
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Edited Feb 02, 2021 by John Ericson
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking