This project is mirrored from Pull mirroring updated .
  1. 19 Feb, 2016 1 commit
  2. 16 Feb, 2016 2 commits
    • Mikhail Glushenkov's avatar
      Implement mtime delay calibration. · c4390c84
      Mikhail Glushenkov authored
    • Mikhail Glushenkov's avatar
      Improve the 'getModTime' implementation. · 699a0fea
      Mikhail Glushenkov authored
      Two changes:
        * 'getModTime' now uses 'modificationTimeHiRes' instead of 'modificationTime'
          on Unix when the former is available.
        * 'ModTime' is now represented as a 64-bit unsigned integer in Windows UTC
          format (that is, 100 ns resolution and day zero is 1601-01-01) on all
          platforms. Previously we used POSIX seconds, which was wrong (low
          resolution). Sandbox timestamp files in old format are now up-converted on
          the fly.
      Fixes #3132.
  3. 15 Feb, 2016 1 commit
  4. 14 Feb, 2016 3 commits
  5. 07 Feb, 2016 3 commits
  6. 31 Jan, 2016 1 commit
    • Tomas Vestelind's avatar
      Add new 'user-config' subcommand 'init'. · fe7b5975
      Tomas Vestelind authored and Mikhail Glushenkov's avatar Mikhail Glushenkov committed
      'cabal user-config init' creates a default config file if it doesn't already
      If '--config-file' is set, then that file will be written.
      If '-f' or '--force' is used, then the file will be overwritten if it already
  7. 16 Jan, 2016 3 commits
    • Edward Z. Yang's avatar
      Distinguish between component ID and unit ID. · ef41f44e
      Edward Z. Yang authored
      GHC 8.0 is switching the state sponsored way to specify
      linker names from -this-package-key to -this-unit-id, so
      it behooves us to use the right one.  But it didn't make
      much sense to pass ComponentIds to a flag named UnitId,
      so I went ahead and finished a (planned) refactoring
      to distinguish ComponentIds from UnitIds.
      At the moment, there is NO difference between a ComponentId
      and a UnitId; they are identical.  But semantically, a
      component ID records what sources/flags we chose (giving us enough
      information to typecheck a package), whereas a unit ID records
      the component ID as well as how holes were instantiated
      (giving us enough information to build it.)  MOST code
      in the Cabal library wants unit IDs, but there are a few
      places (macros and configuration) where we really do
      want a component ID.
      Some other refactorings that got caught up in here:
          - Changed the type of componentCompatPackageKey to String, reflecting the
            fact that it's not truly a UnitId or ComponentId.
          - Changed the behavior of CURRENT_PACKAGE_KEY to unconditionally
            give the compatibility package key, which is actually what you
            want if you're using it for the template Haskell trick.  I also
            added a CURRENT_COMPONENT_ID macro for the actual component ID,
            which is something that the Cabal test-suite will find useful.
          - Added the correct feature test for GHC 8.0 ("Uses unit IDs").
      Signed-off-by: default avatarEdward Z. Yang <>
    • kristenk's avatar
      Change default flag value to True in solver DSL. · 2bac1fe7
      kristenk authored
      This default is consistent with Cabal.
    • kristenk's avatar
      Fix typos in solver test case comment. · 9bbd4f82
      kristenk authored
  8. 14 Jan, 2016 4 commits
  9. 04 Jan, 2016 1 commit
    • Duncan Coutts's avatar
      Fix tar tests · fd3dd32d
      Duncan Coutts authored
      No need to test functions that come from the tar lib now.
      Also, correct the expected output for sandbox remove source. Previously
      the results were expected to come out in reverse order, because the old
      filterEntriesM performed the monad actions in reverse order. The new
      code doesn't have that bug so the results come out in the correct order.
  10. 26 Dec, 2015 1 commit
  11. 25 Nov, 2015 1 commit
  12. 24 Nov, 2015 1 commit
  13. 19 Nov, 2015 1 commit
  14. 09 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Implement ComponentId, replacing PackageKey and InstalledPackageId. · b083151f
      Edward Z. Yang authored
      Today in Cabal, when you build and install a package, it is
      uniquely identified using an InstalledPackageId which is computed
      using the ABI hash of the library that was installed.  There
      are few problems with doing it this way:
          - In a Nix-like world, we should instead uniquely identify
            build products by some sort of hash on the inputs to the
            compilation (source files, dependencies, flags).  The ABI
            hash doesn't capture any of this!
          - An InstalledPackageId suggests that we can uniquely identify
            build products by hashing the source and dependencies of
            a package as a whole.  But Cabal packages contain many components:
            a library, test suite, executables, etc.  Currently, when
            we say InstalledPackageId, we are really just talking about
            the dependencies of the library; however, this is unacceptable
            if a Cabal package can install multiple libraries; we need
            different identifiers for each.
          - We've also needed to compute another ID, which we've called
            the "package key", which is to be used for linker symbols
            and type equality GHC-side.  It is confusing what the distinction
            between this ID and InstalledPackageIds are; the main reason
            we needed another ID was because the package key was needed
            prior to compilation, whereas the ABI hash was only available
      This patch replaces InstalledPackageId and PackageKey with a
      new identifier called ComponentId, which has the following
          - It is computed per-component, and consists of a package
            name, package version, hash of the ComponentIds
            of the dependencies it is built against, and the name
            of the component.  For example, "foo-0.1-abcdef" continues
            to identify the library of package foo-0.1, but
            "foo-0.1-123455-foo.exe" would identify the executable,
            and "foo-0.1-abcdef-bar" would identify a private sub-library
            named bar.
          - It is passed to GHC to be used for linker symbols and
            type equality.  So as far as GHC is concerned, this is
            the end-all be-all identifier.
          - Cabal the library has a simple, default routine for computing
            a ComponentId which DOES NOT hash source code;
            in a later patch Duncan is working on, cabal-install can
            specify a more detailed ComponentId for a package
            to be built with.
      Here are some knock-on effects:
          - 'id' is a ComponentId
          - 'depends' is now a list of ComponentIds
          - New 'abi' field to record what the ABI of a unit is (as it is no longer
            computed by looking at the output of ghc --abi-hash).
          - The 'HasInstalledPackageId' typeclass is renamed to
          - GHC 7.10 has explicit compatibility handling with
            a 'compatPackageKey' (an 'ComponentId') which is
            in a compatible format.  The value of this is read out
            from the 'key' field.
      Signed-off-by: default avatarEdward Z. Yang <>
  15. 27 Aug, 2015 1 commit
  16. 26 Aug, 2015 1 commit
  17. 31 Jul, 2015 2 commits
  18. 30 Jul, 2015 3 commits
  19. 21 Jul, 2015 1 commit
    • Edward Z. Yang's avatar
      Refactor Cabal around the idea of "library names". · f47732a5
      Edward Z. Yang authored
      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: default avatarEdward Z. Yang <>
  20. 06 Jul, 2015 1 commit
  21. 05 Jul, 2015 1 commit
    • Oleg Grenrus's avatar
      Fix #2704 · f9467833
      Oleg Grenrus authored
      Code branch with zlib <0.6 cannot recognise the uncompressed input.
  22. 03 Jul, 2015 2 commits
    • Oleg Grenrus's avatar
      Correct maybeDecompress · fd64fce1
      Oleg Grenrus authored and Duncan Coutts's avatar Duncan Coutts committed
    • Matthias Fischmann's avatar
      Upgrade to zlib >=0.6. · a1ba3d0a
      Matthias Fischmann authored and Duncan Coutts's avatar Duncan Coutts committed
      Fix: 7.4.2 compat.
      PVP compliance: upper version bound.
      Revert noise and relax zlib min version back to 0.5.3 (part 1/2).
      Revert noise and relax zlib min version back to 0.5.3 (part 2/2).
      Test cases for maybeDecompress.
      Use edsko's implementation of maybeDecompress; add test case.
      maybeDecompress: test suite work-around.
      Relax zlib upper bound.
      maybeDecompress: add mysteriously failing test cases.
      7.4 compat for test cases.
  23. 29 Jun, 2015 2 commits
  24. 26 Jun, 2015 1 commit
  25. 01 Jun, 2015 1 commit