GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:40:14Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9508Rename package key2019-07-07T18:40:14ZEdward Z. YangRename package keyWe were planning on renaming package key to something different. The two proposals on the table are "package instance" (which I don't like) and "library ID".
<details><summary>Trac metadata</summary>
| Trac field | Value ...We were planning on renaming package key to something different. The two proposals on the table are "package instance" (which I don't like) and "library ID".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Rename package key","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.9","keywords":["backpack"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"We were planning on renaming package key to something different. The two proposals on the table are \"package instance\" (which I don't like) and \"library ID\".","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9265Create PackageKey to replace PackageId, including version dependency information2019-07-07T18:41:08ZEdward Z. YangCreate PackageKey to replace PackageId, including version dependency information[Multipleinstalledinstancesofapackage](commentary/packages/multi-instances) has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoC project](wiki:Commentary/GSoCMultipleInstances) that ultimately nev...[Multipleinstalledinstancesofapackage](commentary/packages/multi-instances) has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoC project](wiki:Commentary/GSoCMultipleInstances) that ultimately never got merged into HEAD.
This ticket is our latest attack on the problem, summarized as: add a version dependency hash to the `PackageId` (NOT the `InstalledPackageId`) associated with packages in the database. This approach is distinguished from the prior attempts as follows:
- We make no attempt to support multiple installations of different ways or ABI-compatible versions of a library (e.g. with/without optimizations.) This corresponds to supporting multiple InstalledPackageIds in a database; in our case, we're supporting multiple `PackageId`.
- We do not have to deal with conflicting "instances" in GHC's package resolver: multiple instances can be simultaneously loaded and used in a single compiled program. This is because PackageIds are baked into the exported linker symbols, so different versions will have different names and can peacefully coexist.
- We do not have to deal with the delicate ordering problem of calculating an ABI hash when configuring a package, which is prior to when we actually know it (ABI hash is only known after compilation), because our hash is based ONLY on dependency resolution choice.
- In absence of preference for previously installed packages, our Cabal dependency resolution stays exactly the same: Cabal picks versions, and from these choices we calculate the dependency hashes. With preference, we will have to do a little more work.
- We do not attempt to garbage collect old packages. Because we are not dependent on ABI, there is not an explosion of installed pacakges from package development; new installed packages only occur when version numbers are bumped up, or packages are installed in a combinatorially different fashion.7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9243Recompilation avoidance doesn't work for -fno-code/-fwrite-interface2019-07-07T18:41:13ZEdward Z. YangRecompilation avoidance doesn't work for -fno-code/-fwrite-interfaceWith the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface fil...With the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface files are up-to-date.
However, this does not currently work: we always re-typecheck:
```
t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface
[1 of 1] Compiling A ( A.hs, nothing )
t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface
[1 of 1] Compiling A ( A.hs, nothing )
```
The reason for this is that recompilation avoidance logic in `compileOne` (in `DriverPipeline.hs`) seems to rely exclusively on "linkables" in order to figure out if source has been modified or not. We never generate an object file with `-fwrite-interface`, so the compiler always concludes that we need to retypecheck.
However, recompilation avoidance for hs-boot does work. The reason for this is because we create a dummy o-boot linkable. We can't use this strategy for `-fno-code`, because the dummy object file would imply that we actually compiled the file (which we didn't).
The upshot is that to fix this problem, it looks like we might have to rejigger all of the logic in `compileOne`, which why I gave up on this for now.
Related to https://github.com/haskell/cabal/issues/1179
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface files are up-to-date.\r\n\r\nHowever, this does not currently work: we always re-typecheck:\r\n\r\n{{{\r\nt-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface\r\n[1 of 1] Compiling A ( A.hs, nothing )\r\nt-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface\r\n[1 of 1] Compiling A ( A.hs, nothing )\r\n}}}\r\n\r\nThe reason for this is that recompilation avoidance logic in `compileOne` (in `DriverPipeline.hs`) seems to rely exclusively on \"linkables\" in order to figure out if source has been modified or not. We never generate an object file with `-fwrite-interface`, so the compiler always concludes that we need to retypecheck.\r\n\r\nHowever, recompilation avoidance for hs-boot does work. The reason for this is because we create a dummy o-boot linkable. We can't use this strategy for `-fno-code`, because the dummy object file would imply that we actually compiled the file (which we didn't).\r\n\r\nThe upshot is that to fix this problem, it looks like we might have to rejigger all of the logic in `compileOne`, which why I gave up on this for now.\r\n\r\nRelated to https://github.com/haskell/cabal/issues/1179","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/8407Module re-exports at the package level2019-07-07T18:45:11ZJoachim Breitnermail@joachim-breitner.deModule re-exports at the package levelFor various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice.
I wrote up a design s...For various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice.
I wrote up a design spec at ModuleReexports; this bug is to track the progress.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Module re-exports at the package level","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"For various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice.\r\n\r\nI wrote up a design spec at ModuleReexports; this bug is to track the progress.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yang