This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 17 Dec, 2015 3 commits
    • Edsko de Vries's avatar
      Change Repo type · a8056d47
      Edsko de Vries authored
      The old Repo type has a repoKind
      
          repoKind     :: Either RemoteRepo LocalRepo,
      
      where LocalRepo was isomorphic to unit:
      
          data LocalRepo = LocalRepo
      
      This commit changes Repo to
      
          data Repo =
              -- | Local repositories
              RepoLocal {
                  repoLocalDir :: FilePath
                }
      
              -- | Standard (unsecured) remote repositores
            | RepoRemote {
                  repoRemote   :: RemoteRepo
                , repoLocalDir :: FilePath
                }
      
      instead, which is a little more idiomatic and will make adding more repository
      types easier.
      a8056d47
    • Edsko de Vries's avatar
      Introduce datatype for the Cabal index cache · 2cce2cb8
      Edsko de Vries authored
      Right now this just wraps the list of cache entries, but this might make it
      easier in the future to change the structure of the cache.
      2cce2cb8
    • Edsko de Vries's avatar
      Introduce structured type for specifying index · 99454f73
      Edsko de Vries authored
      In particular, distinguish between the repo-global index and a (sandbox-)local
      index.
      99454f73
  2. 09 Dec, 2015 1 commit
  3. 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
            afterwards.
      
      This patch replaces InstalledPackageId and PackageKey with a
      new identifier called ComponentId, which has the following
      properties:
      
          - 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
            'HasComponentId'.
      
          - 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 <ezyang@cs.stanford.edu>
      b083151f
  4. 17 Sep, 2015 3 commits
  5. 30 Jul, 2015 1 commit
  6. 17 Jun, 2015 1 commit
  7. 31 May, 2015 1 commit
  8. 20 May, 2015 1 commit
    • Duncan Coutts's avatar
      Handle multiple preferred-versions in the index tarball better · 36265fb1
      Duncan Coutts authored
      The existing code supports reading multiple preferred-versions files in
      the 00-index.tar and merging them. However it doesn't do it quite right
      when the same file is updated, it merged them instead of the later one
      overriding the first.
      
      This should make no difference right now because the 00-index.tar
      typically only contains a single preferred-versions file, with no
      updates.
      36265fb1
  9. 28 Mar, 2015 1 commit
  10. 10 Mar, 2015 1 commit
  11. 06 Mar, 2015 1 commit
  12. 24 Oct, 2014 2 commits
  13. 11 Oct, 2014 2 commits
  14. 27 Aug, 2014 1 commit
  15. 25 Jul, 2014 1 commit
    • Mikhail Glushenkov's avatar
      Replace a '>=' comparison with a '>'. · 440fe65e
      Mikhail Glushenkov authored
      It looks like #1443 was actually fixed by the change from getModificationTime to
      getModTime (which has higher resolution). The change to '>=' was not needed
      because the code uses 'when', not 'unless'.
      
      Thanks to Nikita Karetnikov for the heads-up.
      440fe65e
  16. 27 Apr, 2014 2 commits
  17. 14 Apr, 2014 1 commit
  18. 19 Dec, 2013 2 commits
  19. 27 Aug, 2013 1 commit
  20. 25 Aug, 2013 1 commit
  21. 23 Aug, 2013 2 commits
  22. 09 May, 2013 1 commit
  23. 02 May, 2013 1 commit
  24. 29 Apr, 2013 4 commits
  25. 28 Apr, 2013 3 commits
  26. 05 Nov, 2012 1 commit