In GHC 7.10, Cabal always generate package keys, including in cases where Backpack was involved (e.g. --instantiated-with). In fact, in these case, GHC needs to be able to generate the package key (because it will often make a substitution on the instantiation, and needs to know if this identity coincides with anything else we've seen previously). Thus, we introduce a new notion, the 'LibraryName', which is JUST the non-Backpack portion of a package key. For ordinary packages that are definite, a 'LibraryName' is simply the 'PackageId' plus 'PackageKey'; for indefinite Backpack packages, when a package gets instantiatied, it may end up with different 'PackageKey's even though the 'LibraryName' stays the same. 'LibraryName's can be computed purely by Cabal. This patch: - Defines library name, which are the source package ID plus a hash of all the source package ID and the library names of external, textual dependencies, - Redefines the package key to be JUST the hash portion of a library name, in the case that Backpack is not used, - Records the library name in InstalledPackageInfo. Note: the source package ID is included both externally (so the library name is a useful handle to refer to package) and internally (so the hash can stand alone as the package key.) A major refactoring which is part of this commit is moving package keys/library names from LocalBuildInfo to LibComponentBuildInfo. If you have an LBI, you can still extract a package key/library name using the new localPackageKey/localLibraryName function (which looks through the ComponentBuildInfos of a LocalBuildInfo for the library in question). This is conceptually cleaner for two reasons: 1. Only dependencies of the *library* are counted as part of the library name, as opposed to *all* dependencies which we previously used. 2. A library name doesn't really mean much for an executable, or a test suite, since no one else will have to link against them. So we can fall back on something simpler. A more minor refactoring is the 'LibraryName' type, which was previously defined by LocalBuildInfo and generally looked something like "HSprocess-0.1-XXXX". We change the meaning of 'LibraryName' to be "process-0.1-XXXX" (thus we have to insert some HS additions in the code) and eliminate componentLibraries, thus assuming that there is only ONE Haskell library (which was the case.) So we remove a little bit of generality and in return get code that is much easier to read. (The only downside is GHC's hack to split DLLs into multiples has to be adjusted slightly, but this is not a big price to pay.) Signed-off-by: Edward Z. Yang <firstname.lastname@example.org>
Introduce a new superclass HasInstalledPackageId: class Package pkg => HasInstalledPackageId pkg where installedPackageId :: pkg -> InstalledPackageId class HasInstalledPackageId pkg => PackageInstalled pkg where installedDepends :: pkg -> [InstalledPackageId] Most functions that deal with the package index now just require HasInstalledPackageId; only the functions that actually require the dependencies still rely on PackageInstalled. The point is that a ConfiguredPackage/ReadyPackage/PlanPackage can reasonably be made an instance of HasInstalledPackageId, but not of PackageInstalled; that will be the topic of the next, much larger, pull request.
The fundamental difference between Cabal and cabal-install is that the former deals with installed libraries, and -- in principle -- knows about _library_ dependencies only, whereas the latters deals with setup, executable, test-suite and benchmark dependencies in addition to library dependencies. Currently we classify all of these simply as 'dependencies' but that will change shortly. In this commit we take a first step towards this by moving the PackageFixedDeps class, which deals with dependencies of packages rather than installed libraries, from Cabal to cabal-install. The commit is pretty simple; we just move the type class and update import statements where necessary.
Signed-off-by: Edward Z. Yang <email@example.com>
Signed-off-by: Edward Z. Yang <firstname.lastname@example.org>
GHC generics are used to derive binary instances for types appearing in the persistent build config, which requires GHC >= 7.2 and binary >= 0.7. Unfortunately, GHC < 7.8 ships with binary == 0.5.*. The missing module is Data.Binary.Generics, which we have copied from binary-0.7.2.3 to Distribution.Compat.Binary.Generics. To provide generic implementations for the Binary class, we also have to provide our own implementation, which is copied from binary-0.7.2.3 to Distribution.Compat.Binary.Class. The interface required by Cabal is exported from Distribution.Compat.Binary. This is only done if bootstrapping Cabal with GHC < 7.8 or if binary >= 0.7 is not available, otherwise Distribution.Compat.Binary simply re-exports Data.Binary.
…e-with. There's no chrome here, but some of the guts for Cabal supporting compiling signatures. The key UI is a new --instantiate-with flag for ./Setup (no support cabal-install side!) which properly modifies the package key, calculates extra hole dependencies for a package, and ensures an appropriately translated -sig-of is passed to GHC. The UI here is supremely user-unfriendly: the intent is that users will use cabal-install to calculate these parameters for them. ToDo: Cabal's inconsistency check in ./Setup needs to be adjusted to be less zealous. Signed-off-by: Edward Z. Yang <email@example.com>
BC note: renamed type PackageIndex :: * to InstalledPackageIndex. The intent is to have cabal-install use this package index in order to track information about compilation in progress. We introduce a new PackageInstalled type-class to keep track of data types which have their IDs and dependency graphs in InstalledPackageId. Signed-off-by: Edward Z. Yang <firstname.lastname@example.org>
The initial support for module re-exports relied on ghc-pkg to resolve user-specified re-exports to references to specific installed packages. This resolution is something that can fail so it's better for Cabal to do it during the package configure phase. In addition, it is inconvenient in ghc-pkg to be doing this resolution, and it just seems fishy as a design. Also, the same ModuleExport type was being used both for user-specified source re-exports and also for the specific re-exports in the package db. This patch splits the type into two: one for source level, and one for resolved ones for use in the package db. The configure phase resolves one to the other. One minor change: it is now possible to re-export a module defined in the same package that is not itself exported (ie it's in other-modules, rather than exposed-modules). Previously for modules definied in the same package they had to be themselves exported. Of course for re-exports from other packages they have to be exposed.
…deps/flags Previously, the GHC ecosystem assumed that for any package ID (foo-0.1), there would only be one instance of it in the installed packages database. This posed problems for situations where you want a package compiled twice against different sets of dependencies: they could not both exist in the package database. Package keys are a hash of the package ID and package dependencies, which identify a package more uniquely than a package ID, but less uniquely than an installed package ID. Unlike installed package IDs, these can be computed immediately after dependency resolution, rather than after compilation. Package keys require support from the compiler. At the moment, only GHC 7.10 supports package keys (the reason is that old versions of GHC do a sannity check to see that the <pkg-name>-<pkg-version> stored in the package database matches with the -package-name embedded in an hi file; so the format is fixed.) We fallback to package keys == package IDs for old versions. Note: the ./Setup configure fallback script does not try particularly hard to pick consistent sets of dependencies. If your package database is too difficult for it to resolve, manually provide installed package IDs or use cabal-install's dependency solver. Note: This patch *suspends* the reinstall check unless it would result in a different package, so cabal-install will now happily reinstall foo-0.1 compiled against bar-0.2 if foo-0.1 already exists. Signed-off-by: Edward Z. Yang <email@example.com>
Note: this adds an orphan Data instance for Data.Version. A fix has been proposed upstream.
…t 3 years instead of reimplementing it all over the place