This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 18 Sep, 2016 1 commit
  2. 06 Sep, 2016 2 commits
  3. 26 Apr, 2016 1 commit
  4. 25 Apr, 2016 1 commit
  5. 08 Apr, 2016 1 commit
  6. 07 Mar, 2016 1 commit
  7. 06 Mar, 2016 1 commit
  8. 07 Feb, 2016 1 commit
    • Duncan Coutts's avatar
      Add get{Source,Installed}PackagesMonitorFiles · a15318ce
      Duncan Coutts authored
      Re-export getInstalledPackagesMonitorFiles from Cabal lib and add
      getSourcePackagesMonitorFiles locally to D.C.IndexUtils.
      
      These are for tracking changes to these bits of the environment, so that
      it's possible for us to recompute things that depend on them.
      a15318ce
  9. 16 Jan, 2016 1 commit
    • 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 <ezyang@cs.stanford.edu>
      ef41f44e
  10. 12 Jan, 2016 1 commit
  11. 07 Jan, 2016 1 commit
    • Edsko de Vries's avatar
      Introduce RepoContext · ba5c55c4
      Edsko de Vries authored
      The RepoContext encapsulates the list of repositories, as well as some
      associated state. In particular, it also encapsulates the HttpTransport, which
      will be initialized on demand and cached thereafter.  This is important for two
      reasons:
      
      * For the hackage-security integration: in order to be able to use cabal's own
        HttpTransport API for the secure repo, we need to have access to that
        transport when we initialize the repo, but as things stood that was not
        possible (cabal was initializing repos ahead of time but the transport on
        demand).
      
      * For the integration with the nix-local-branch it is important that the Repo
        type remains Serializable. By passing RepoContext rather than a list of
        Repos, we can leave RepoSecure serializable and separately maintain a mapping
        from cabal's Repo type to hackage-security's (stateful) Repository type.
      ba5c55c4
  12. 05 Jan, 2016 2 commits
  13. 04 Jan, 2016 1 commit
    • Duncan Coutts's avatar
      Switch to the tar package, drop builtin code · 0db3b216
      Duncan Coutts authored
      The current incarnation of the tar package originated as code inside
      cabal-install. That external tar package is now quite mature, with more
      features and is much faster. In particular the tar index features will
      be very useful for cabal-install, which currently has to maintain its
      own custom-format index/cache.
      0db3b216
  14. 27 Dec, 2015 1 commit
  15. 21 Dec, 2015 1 commit
  16. 18 Dec, 2015 1 commit
  17. 17 Dec, 2015 4 commits
    • Edsko de Vries's avatar
      Address comments on #2949. · ef6fe247
      Edsko de Vries authored
      This changes the definition of `Index` to
      
      ``` haskell
      data Index =
          -- | The main index for the specified repository
          RepoIndex Repo
      
          -- | A sandbox-local repository
          -- Argument is the location of the index file
        | SandboxIndex FilePath
      ```
      
      with
      
      ```
      cacheFile (SandboxIndex index) = index `replaceExtension` "cache"
      ```
      
      This also renames `repoRemote'` to `maybeRepoRemote`.
      
      I believe this addresses all comments.
      ef6fe247
    • 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
  18. 09 Dec, 2015 1 commit
  19. 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
  20. 17 Sep, 2015 3 commits
  21. 30 Jul, 2015 1 commit
  22. 17 Jun, 2015 1 commit
  23. 31 May, 2015 1 commit
  24. 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
  25. 28 Mar, 2015 1 commit
  26. 10 Mar, 2015 1 commit
  27. 06 Mar, 2015 1 commit
  28. 24 Oct, 2014 2 commits
  29. 11 Oct, 2014 2 commits
  30. 27 Aug, 2014 1 commit
  31. 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