{"push_id":731983289,"size":1,"distinct_size":1,"ref":"refs/heads/cabal-version-hash","head":"df491f93274e4d5c25f3cf6392bd8ee852462d9c","before":"ab69f3af4474d8ab9f1986844e9ed345989ee565","commits":[{"sha":"df491f93274e4d5c25f3cf6392bd8ee852462d9c","author":{"email":"dbd597f5635f432486c5d365e9bb585b3eaa1853@cs.stanford.edu","name":"Edward Z. Yang"},"message":"Refactor Cabal around the idea of \"library names\".\n\nIn GHC 7.10, Cabal always generate package keys, including in\ncases where Backpack was involved (e.g. --instantiated-with).\nIn fact, in these case, GHC needs to be able to generate the\npackage key (because it will often make a substitution on the\ninstantiation, and needs to know if this identity coincides with\nanything else we've seen previously).\n\nThus, we introduce a new notion, the 'LibraryName', which\nis JUST the non-Backpack portion of a package key.  For ordinary\npackages that are definite, a 'LibraryName' is simply\nthe 'PackageId' plus 'PackageKey'; for indefinite Backpack packages,\nwhen a package gets instantiatied, it may end up with different\n'PackageKey's even though the 'LibraryName' stays the same.\n'LibraryName's can be computed purely by Cabal.\n\nThis patch:\n\n    - Defines library name, which are the source package ID plus\n      a hash of all the source package ID and the library names of external,\n      textual dependencies,\n\n    - Redefines the package key to be JUST the hash portion of a\n      library name, in the case that Backpack is not used,\n\n    - Records the library name in InstalledPackageInfo.\n\nNote: the source package ID is included both externally (so the library\nname is a useful handle to refer to package) and internally (so the\nhash can stand alone as the package key.)\n\nA major refactoring which is part of this commit is moving package keys/library\nnames from LocalBuildInfo to LibComponentBuildInfo.  If you have an LBI, you can\nstill extract a package key/library name using the new\nlocalPackageKey/localLibraryName function (which looks through the\nComponentBuildInfos of a LocalBuildInfo for the library in question).  This is\nconceptually cleaner for two reasons:\n\n    1. Only dependencies of the *library* are counted as part\n    of the library name, as opposed to *all* dependencies which\n    we previously used.\n\n    2. A library name doesn't really mean much for an executable,\n    or a test suite, since no one else will have to link against\n    them.  So we can fall back on something simpler.\n\nA more minor refactoring is the 'LibraryName' type, which was\npreviously defined by LocalBuildInfo and generally looked something\nlike \"HSprocess-0.1-XXXX\".  We change the meaning of 'LibraryName'\nto be \"process-0.1-XXXX\" (thus we have to insert some HS additions\nin the code) and eliminate componentLibraries, thus assuming that\nthere is only ONE Haskell library (which was the case.)  So\nwe remove a little bit of generality and in return get code\nthat is much easier to read.  (The only downside is GHC's hack\nto split DLLs into multiples has to be adjusted slightly, but\nthis is not a big price to pay.)\n\nSigned-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>","distinct":true,"url":"https://api.github.com/repos/ezyang/cabal/commits/df491f93274e4d5c25f3cf6392bd8ee852462d9c"}]}