This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 27 Dec, 2016 1 commit
    • Edward Z. Yang's avatar
      Refactor Backpack data structures to be less flexible. · 28af355b
      Edward Z. Yang authored
      
      
      There were a number of fields in 'LinkedComponent' which
      were "too" flexible, in that they were fully determined by
      other fields in the structure.  This refactor deletes those
      fields and replaces them with functions that refer to the
      fields directly.
      
      I also introduce a new type, ComponentInclude, to take
      the place of tuples which were used to represent includes
      (mixins) in Backpack.
      
      There's also more documentation for lots of bits.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      28af355b
  2. 20 Dec, 2016 1 commit
  3. 27 Nov, 2016 1 commit
  4. 17 Nov, 2016 1 commit
  5. 14 Nov, 2016 1 commit
  6. 01 Nov, 2016 1 commit
  7. 31 Oct, 2016 1 commit
  8. 29 Oct, 2016 1 commit
    • Jason Dagit's avatar
      Require Cabal >= 1.20 in new-build. (#4051) · 80de7ff4
      Jason Dagit authored
      Constrain Cabal >= 1.20 in all new-build install plans. This solves problems where Cabal 1.18 don't have a good enough API to let us handle the new-style store (we need --dependency flags.)
      
      In the future we plan to relax this to only Setup.hs dependencies.
      
      Fixes issue #3932.
      80de7ff4
  9. 28 Oct, 2016 1 commit
    • Edsko de Vries's avatar
      Add support for foreign libraries. · 382143aa
      Edsko de Vries authored
      A stanza for a platform library looks something like
      
          platform-library test-package
            type:                native-shared
      
            if os(Windows)
              options: standalone
              mod-def-file: TestPackage.def
      
            other-modules:       MyPlatformLib.Hello
                                 MyPlatformLib.SomeBindings
            build-depends:       base >=4.7 && <4.9
            hs-source-dirs:      src
            c-sources:           csrc/MyPlatformLibWrapper.c
            default-language:    Haskell2010
      
      where native-shared means that we want to build a native shared library
      (.so on Linux, .dylib on OSX, .dll on Windows). The parser also
      recognizes native-static but this is not currently supported anywhere.
      The standalone option means that the we merge all library dependencies
      into the dynamic library (i.e., ghc options -shared -static), rather
      than make the created dynamic library just record its dependencies (ghc
      options -shared -dynamic); it is currently compulsory on Windows and
      unsupported anywhere else. The mod-def-file can be used to specify a
      module definition file, and is also Windows specific.
      
      There is a bit of refactoring in Build: gbuild is the old buildOrReplExe
      and now deals with both executables and platform libraries.
      382143aa
  10. 25 Oct, 2016 1 commit
    • Edward Z. Yang's avatar
      Drop version check when resolving package names. · af24cefe
      Edward Z. Yang authored
      
      
      In #4017, hvr reported that when he used --allow-older/--allow-newer,
      there was an assert failure in toConfiguredComponent.  Indeed
      the problem was that toConfiguredComponent was testing version
      ranges of build-depends to determine which package to select, but
      there was no satisfying one (since the build-depends field had
      not been updated.)
      
      After thinking about this for a bit, it seemed a bit bogus for
      us to be doing another version check at this late phase; we
      already picked dependencies earlier in the configuration process.
      So I decided to drop it.
      
      To drop it, however, I needed to remove support for a feature (discussed
      in #4020), which uses version ranges to disambiguate whether or not a
      dependency is on an external package or an internal package.  This
      feature doesn't seem to be very useful.  If someone asks, I'll
      check on Hackage to see if anyone is using it.
      
      Also added some useful extra debug info.
      
      Fixes #4020 and #4017
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      af24cefe
  11. 22 Oct, 2016 1 commit
  12. 21 Oct, 2016 3 commits
  13. 18 Oct, 2016 3 commits
  14. 08 Oct, 2016 1 commit
  15. 06 Oct, 2016 9 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      c2870d7e
    • Edward Z. Yang's avatar
      Add a new 'DefUnitId' type with invariant. · bd3040bd
      Edward Z. Yang authored
      
      
      The DefUnitId invariant says that the UnitId in a DefUnitId
      must in fact be a definite package (either with no holes, or
      fully instantiated.)  This is in constrast to a UnitId,
      which can also identify an indefinite unit identifier.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bd3040bd
    • Edward Z. Yang's avatar
      Rename IndefModule to OpenModule. · 2e42ca27
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2e42ca27
    • Edward Z. Yang's avatar
      Rename IndefUnitId to OpenUnitId. · 62ddf8e0
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      62ddf8e0
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      cabal-install changes for Backpack. · 69cfeec2
      Edward Z. Yang authored
      
      
      Here are the main changes:
      
      Distribution/Client/InstallPlan.hs
          New utility function 'fromSolverInstallPlanWithProgress'
          which is a monadic version of 'fromSolverInstallPlan'.
          This is because, with Backpack, the conversion from
          'SolverInstallPlan' to 'InstallPlan' can fail/log.
      
      Distribution/Client/ProjectPlanning/Types.hs
          OK. A bunch of new information we need to track.
      
          New fields in 'ElaboratedConfiguredPackage':
              elabInstantiatedWith :: ModuleSubst (for --instantiated-with)
              elabLinkedInstantiatedWith :: IndefModuleSubst (intermediate)
              elabModuleShape :: ModuleShape (for mix-in linking)
      
          Here is how all the dependency functions relate to
          one another:
      
              elabOrderDependencies :: [UnitId]
                  Used for nodeNeighbors, this just specifies what needs
                  to be built before we build this module.  These refer
                  either to fully instantiated unit ids (hashed unit id)
                  or uninstantiated unit ids (effectively component id)
                  but never a partially instantiated unit id, since we
                  never have an install item in our plan for a partially
                  instantiated package.
      
                  These dependencies are factored into two parts:
                      elabOrderLibDependencies
                      elabOrderExeDependencies
                  which soley are used to determine if we need to enable
                  executables/libraries of a package we are building
                  (this isn't new)
      
              elabLibDependencies :: [ComponentId]
                  These are the things we pass to Setup using the --dependency
                  flag; so they are JUST ComponentId, not a full on UnitId.
                  The mix-in linking process in Setup will reconstruct the
                  necessary UnitId.
      
              elabExeDependencies :: [ComponentId]
                  These are the things that we must add to the PATH to run.
                  At the moment, this coincides with elabOrderExeDependencies.
      
          For components, there is also:
      
              compLinkedLibDependencies :: [IndefUnitId],
                  The partially instantiated unit ids that GHC would be
                  invoked with, if we were invoking it directly.
                  This is used when we subsequently instantiate components.
      
              compNonSetupDependencies :: [UnitId]
                  Non-setup, ORDER dependencies; i.e., everything that has
                  to be built before us that is not a setup script.
      
      Distribution/Client/ProjectPlanning.hs
          The workhorse.
      
          Essentially, we redo all of the steps from
          Distribution.Backpack.Configure, but in the context of planning an
          entire install plan.  The conversion from SolverInstallPlan
          to InstallPlan is responsible for mix-in linking
          (inside elaborateSolverToComponents); afterwards,
          instantiateInstallPlan is responsible for filling in
          the missing, instantiated packages which we need to compile.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      69cfeec2
    • Edward Z. Yang's avatar
      Use the new Backpack code for the configure step · 688b31e3
      Edward Z. Yang authored
      Many of the configure functions were factored out and moved to the new
      Backpack modules. The new configure action makes a call to
      Distribution.Backpack.Configure to setup the ComponentLocalBuildInfo.
      
      Also add an @--instantiate-with@ flag to ./Setup configure, so that
      cabal-install can specify how it wants to instantiate a package that
      it is building.
      
      Also do the minimal necessary adjustments in cabal-install.
      688b31e3
    • Edward Z. Yang's avatar
      Introduce the new representation of UnitId · d7bd9078
      Edward Z. Yang authored
      'SimpleUnitId' constructor renamed to 'UnitId', and augmented
      with a new field 'Maybe String' recording a hash that uniquely
      identifies an instantiated unit of the library 'ComponentId'.
      'UnitId' can't be used to represent partially instantiated
      unit identifiers; see Distribution.Backpack for how we handle that.
      
      Previous uses of 'SimpleUnitId' should now use 'newSimpleUnitId'.
      'unitIdComponentId' folded into a record selector for 'ComponentId'.
      d7bd9078
  16. 30 Sep, 2016 1 commit
  17. 29 Sep, 2016 1 commit
    • Duncan Coutts's avatar
      Go back to the plan.json reflecting only env inputs · 602a5434
      Duncan Coutts authored
      In particular it will not reflect the status of the build, ie it will
      list all the source packages and their configuration but not say if
      they're already installed in the store.
      
      There's a slightly vauge principle at work here, that we should
      distinguish between build outputs and build ststus: build outputs
      should be (morally) pure functions of the environment, where as build
      status is about the degree to which the current cached outputs reflect
      the state of the inputs (ie are build outputs up to date or not).
      
      So in this case that means the plan.json is considered an output and
      thus it should not depend on the state of the store. We can certainly
      provide machine readable status info, but this should be a separate
      thing.
      602a5434
  18. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      
      Finally, this also adds a new functor-like convenience function
      
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      
      for modifying the version number components.
      bb2026c4
  19. 27 Sep, 2016 2 commits
    • Arian van Putten's avatar
      Make interactive setup delegate CTRL+C · 005f6dfa
      Arian van Putten authored
      Fixes #3899
      
      When cabal new-repl spawns ghci, it spawns this as a subprocess.
      In UNIX like systems, if a CTRL+C is sent to this child process
      it also bubbles up to the parent process, causing it to terminate.
      Also see https://hackage.haskell.org/package/process-1.4.2.0/docs/System-Process.html#g:4.
      
      However, this is not what we want for interactive subprocesses.
      Interactive processes usually define their own handlers for CTRL+C,
      for example GHCi uses CTRL+C to reset the input buffer. So instead
      of terminating on CTRL+C we want to delegate CTRL+C to GHCi
      and let it do its thing.
      
      Luckily, we can enable CTRL+C delegation such that the parent
      process ignores the CTRL+C and instead delegates it to the
      child process.
      005f6dfa
    • Herbert Valerio Riedel's avatar
      Make `PackageName` type opaque (#3896) · dabd9d98
      Herbert Valerio Riedel authored
      When looking at heap-profiles of `cabal-install`, the `(:)` constructor
      stands out as the most-allocated constructor on the heap.
      
      Having to handle 10k+ package names contributes to the allocation
      numbers, especially on 64bit archs where ASCII `String`s have a 24 byte
      per character footprint.
      
      This commit is a preparatory commit to pave the way for changing
      `PackageName`'s internal representation to something like
      `ShortByteString` (which is essentially a thin wrapper around primitive
      `ByteArray#`s which themselves have have an overhead of 2 words + one
      byte per ASCII character rounded up to nearest word) which would allow
      to reduce the memory footprint by a full order of magnitude, as well as
      reduce pointer chasing and GC overhead.
      dabd9d98
  20. 26 Sep, 2016 1 commit
  21. 24 Sep, 2016 5 commits
    • Herbert Valerio Riedel's avatar
    • Duncan Coutts's avatar
      Refactor implementation of InstallPlan.installed · d5288df0
      Duncan Coutts authored
      All the use sites (currently only two but soon to be three) use
      InstallPlan.installed to do a bulk change of states, differing only in
      the filter condition. So it simplifies things and shares more code if
      we make the main one be the bulk version. The InstallPlan.remove already
      works similarly.
      d5288df0
    • Duncan Coutts's avatar
      Simplify plan improvement, avoid reading store ghc-pkg db · bf0b5dfe
      Duncan Coutts authored
      Install plan improvement is the process of replacing configured source
      packages with installed instances from the store. Originally we did this
      by reading the ghc-pkg db to get the InstalledPackageInfo for all the
      packages in the store. We had to do that because when we replaced
      configured source packages by installed instances we used the
      PreExisting constructor which requires an InstalledPackageInfo, which we
      get from the installed package db. But now that we no longer use
      PreExisting for packages from the store we also no longer need the
      InstalledPackageInfo. All we need is a set of UnitIds. Also, once
      support for depending on executables was added then we needed a way to
      do plan improvement for executable packages/components. We did this by
      the simple approach of grabbing the dir listing for the store and using
      that as a set of UnitIds.
      
      So this patch extends the approach we use for executables and uses it
      for all packages. This means we no longer load the package db for the
      store.
      
      Note that still need to create the package db in the store. Previously
      we would create it when getting the package db contents, but we don't
      do that any more, but we still need to make sure the db exists.
      
      This also relates to the locking protocol in the store. The goal for the
      store is to be able to access and update it concurrently. The locking
      protocol will include checking membership by checking if the directory
      entry for the package is present. So this patch gets us to the right
      point for the reading side, leaving the writing side to do.
      bf0b5dfe
    • Duncan Coutts's avatar
      Start using new InstallPlan.Installed state · 0de4177c
      Duncan Coutts authored
      Change improvement and --dry-run phases to use Installed state rather
      than the PreExisting state. This means that PreExisting is now only used
      for installed packages from the global db, and never for installed
      packages from the store.
      0de4177c
    • Duncan Coutts's avatar
      Add an Installed state to InstallPlan packages · 435725ef
      Duncan Coutts authored
      This patch just adds the state without yet using it. That'll follow in
      subsequent patches.
      
      So why add an Installed state? Didn't we just remove the Installed,
      Processing and Failed states? Those states were used when we followed
      the approach of updating the InstallPlan as a build progressed (whereas
      we now do traversals without altering the InstallPlan).
      
      The idea of adding an Installed state now is that we can more usefully
      represent the state of the plan when we "improve" the plan with packages
      from the store or when we update the plan having checked if inplace
      packages are up to date. Currently in these two places we replace
      Configured source packages with PreExisting packages. There's a couple
      problems with this. Firstly the PreExisting state only contains an
      InstalledPackageInfo which means we loose information compared to all
      the detail in the Configured source package. This is relevant for things
      like plan.json output or other features that want to know the status of
      a project. Secondly we have to fake things for executables since they
      are not properly represented by InstalledPackageInfo.
      435725ef
  22. 23 Sep, 2016 1 commit
    • Duncan Coutts's avatar
      New Rebuild monad utils and use in ProjectPlanning · c7d55c3c
      Duncan Coutts authored
      Monitored variants of createDirectory and getDirectoryContents.
      Define thee wrappers in the RebuildMonad module so we have fewer
      open-coded tricky monitorFiles calls.
      
      In particular replace a glob monitor on the content of the store with a
      monitor on the store directory itself. This is valid based on the
      behaviour of directory mtimes, which is specified by posix and we have a
      sanity check for it in the unit tests.
      c7d55c3c
  23. 20 Sep, 2016 1 commit