This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 20 Jul, 2020 1 commit
  2. 18 May, 2020 1 commit
    • Oleg Grenrus's avatar
      Make cabal-install compilable with NoImplicitPrelude · d4fd273b
      Oleg Grenrus authored
      I.e. find out where we don't yet
      used `Distribution.Client.Compat.Prelude`.
      
      - If the module is small I added direct `Prelude` imports.
      - Add Exception, deepseq stuff to Cabal Prelude
      - Add Parsec, Pretty and Verbosity to Client Prelude
      - use for, for_, traverse and traverse_ (removes need for Control.Monad)
      d4fd273b
  3. 12 Apr, 2020 1 commit
  4. 20 Dec, 2019 1 commit
  5. 11 Dec, 2019 1 commit
    • Oleg Grenrus's avatar
      Add Distribution.Utils.Structured · ae33fcf9
      Oleg Grenrus authored
      It defines `Structured` type class, which we use to prepend
      a hash to cached `Binary` blobs. Thus we can catch early, if
      format is changed, avoiding corrupt cache making cabal
      behave weirdly.
      
      Plenty types got Typeable instances, as it's a superclass of Structured
      
      This commit also introduces new compat modules:
      
      - Distribution.Compat.Typeable with typeRep
      - Distribution.Client.Compat.Orphans,
        to collect at least some orphans into central place.
      ae33fcf9
  6. 27 Dec, 2018 1 commit
    • Oleg Grenrus's avatar
      Change MungedPackageName to be non-opaque type. · 1a6e2732
      Oleg Grenrus authored
      i.e. strict pair of PackageName and LibraryName
      the legacy conversion is done via Pretty/Parsec instances.
      
      Change of `Maybe UnqualComponentName` to `LibraryName` caused
      a cascade of other changes, but they all seem to be good changes.
      In the sense, they made many comments not-so-necessary.
      
      Add Distribution.Types.PackageName.Magic for special package names.
      
      Updates in cabal-install are mostly trivial type error driven changes.
      I removed few (deprecated) `Text` instances: `MungedPackageId`,
      `MungedPackageName` and `LibraryName`. Turns out only a `Pretty`
      part was used, so it was easy to update. Note: `LibraryName`
      doesn't have `Pretty` / `Parsec` instances as it's either parsed/printed
      as a `ComponentName` or `UnqualComponentName`, never stand alone.
      1a6e2732
  7. 17 Mar, 2017 3 commits
    • Edward Z. Yang's avatar
      Refactor MungedPackageId and PackageIndex. · f4ded04f
      Edward Z. Yang authored
      This makes the necessary changes to 4dc0f30fc36914ee2f01bde016bee98b8e0bb0bb
      to handle component configuring correctly.  It probably is a good step
      towards pkg:lib style dependencies.
      
      The big ideas:
      
      * There's a new AnnotatedId type, which is any identifier (like
        ComponentId), but also with a PackageId and ComponentName.
        It's a bit like ConfiguredId, but ConfiguredId is specialized
        for ComponentId.  There's a conversion function
        annotatedIdToConfiguredId.
      
      * We adopt a totally new strategy for handling MungedPackageId in
        InstalledPackageInfo.  Rather than store the munged package
        identifier in IPI, we NEVER store it, instead computing it
        from the package name and library name (which are stored.)
        There is now code to PARSE a munged package name into these
        two components, so that when we read 'name' we get the
        correct info.  The resulting code is splendidly clear.
      
      * Some places where we took a ComponentName (notably
        computeCompatPackageName) we now take 'Maybe UnqualComponentName'.
        This is more accurate, because compatibility package names are
        only computed for libraries, not other components.  Some code
        in Distribution.Backpack.ReadyComponent is partial now,
        but the invariants should hold up.
      
      * A number of places where MungedId was applied, I undid them.
        Most notable are macro generation (that should be PACKAGES,
        not components) and mkLegacyUnitId (since REALLY old style
        unit identifiers, we won't support internal libraries anyway.)
      
      * Many functions in PackageIndex are monomorphized to
        InstalledPackageInfo.  Fortunately cabal-install's usage
        still works.
      
      * Distribution/Client/SolverPlanIndex.hs, not used by anyone,
        got the axe.
      
      * Dependency solving has a hack to solve the problem of how to
        interpret installed internal libraries in the package database.
        The basic idea is that, although in most cases where we used
        a MungedId, we say it explicitly, in the SOLVER, we munge
        *installed package names* only, and keep the type PackageName.
        It's a hack, but the alternative is to write a lot more code.
        Note that is MORALLY PN is indeed a PackageName, since we really
        are solving for honest to goodness packages, not components!
        See Note [Index conversion with internal libraries] for more
        details.
      
      * ConfiguredId now records the ComponentName.  This is quite important,
        because we need to use it to figure out how we are going to phrase
        --dependency.  In fact, it is a miracle that this worked at all
        (and it only worked because of a very skeevy update to the PackageId
        in the creation of ConfiguredComponent).  Irritatingly, this must
        be a Maybe ComponentName, because a ConfiguredId MIGHT refer to
        a setup component. Very distressing.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      f4ded04f
    • Edward Z. Yang's avatar
      Revert "Revert "Merge pull request #4382 from Ericson2314/munge"" · b0e6c311
      Edward Z. Yang authored
      This reverts commit 4774fb6558974a721176f1fb48d8ce7d43119251.
      b0e6c311
    • Edward Z. Yang's avatar
      Revert "Merge pull request #4382 from Ericson2314/munge" · b1b9d3b1
      Edward Z. Yang authored
      This reverts commit 332d809c, reversing
      changes made to 0c72bc88.
      b1b9d3b1
  8. 09 Mar, 2017 1 commit
  9. 21 Aug, 2016 1 commit
    • Edward Z. Yang's avatar
      Solve for, build, and add to path build-tools dependencies. · c0a48602
      Edward Z. Yang authored
      This fixes #220: new-build now builds, installs and adds executables to
      PATH automatically if they show up in 'build-tools'.  However, there is
      still more that could be done: the new behavior only applies to a
      specific list of 'build-tools' (alex, happy, etc) which Cabal recognizes
      out of the box.  The plan is to introduce a new 'tool-depends' field to
      allow dependencies on other executables as well.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      c0a48602