Skip to content
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

Reexported modules, take 3 #397

Merged
merged 1 commit into from
Aug 10, 2018
Merged

Reexported modules, take 3 #397

merged 1 commit into from
Aug 10, 2018

Commits on Aug 10, 2018

  1. Reexported modules, take 3

    In #385, we claimed to exploit the fact that GHC only needs package
    names in reexport declarations to obviate the need for knowing the
    versions (and dependency hashes) of all prebuilt packages. We provided
    a test to substantiate this indeed works. But it turns that the test
    was not a good test.
    
    The test was flawed because it featured libraries reexporting `base`.
    It turns out that `base` (along with `rts`) are magical in GHC.
    Because they are so-called "wired-in packages", they are assumed
    unique and are therefore not located using a version number. So while
    the scheme in #385 worked for `base`, it didn't work in the general
    case, as observed by @lunaris.
    
    The fix consists qualifying all package reexports with full package
    id's, not package names. How do we derive a package id given only
    a package name? The solution is to have the toolchain generate a dump
    of the global package database that ships with the compiler. This is
    only needed once for the entire workspace. From this dump, we can
    lookup the full package id given any particular name.
    
    Fixes #357.
    mboes committed Aug 10, 2018
    Configuration menu
    Copy the full SHA
    20611b5 View commit details
    Browse the repository at this point in the history