This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 01 Nov, 2017 2 commits
  2. 28 Oct, 2017 1 commit
  3. 27 Oct, 2017 4 commits
  4. 26 Oct, 2017 7 commits
  5. 25 Oct, 2017 2 commits
  6. 23 Oct, 2017 2 commits
  7. 22 Oct, 2017 5 commits
  8. 21 Oct, 2017 5 commits
  9. 20 Oct, 2017 1 commit
    • Moritz Angermann's avatar
      Add note regarding bootstrap to the main README.md · 68b6f6d3
      Moritz Angermann authored
      I've been failing to find this information a few times already. And I still remember not being able to find it the first time, without searching for quite a while. I hope this adds clarity to installing Cabal without cabal, and those who end up with just an unpacked ghc an no cabal to use.
      68b6f6d3
  10. 18 Oct, 2017 1 commit
  11. 15 Oct, 2017 4 commits
  12. 14 Oct, 2017 6 commits
    • Francesco Gazzetta's avatar
      Add a new-install command · 9c62e122
      Francesco Gazzetta authored
      Add the first part of the new-install command: nonlocal exes.
      
      See #4558 for the design concept.
      
      This part of the command installs executables from outside of a project
      (ie from hackage) in the store and then symlinks them in the cabal bin
      directory.
      
      This is done by creating a dummy project and adding the targets as extra
      packages.
      9c62e122
    • Duncan Coutts's avatar
      Wire up extra-packages to be included in the plan · b59d1f7b
      Duncan Coutts authored
      So you can now add `extra-packages: foo` to the cabal.projct file and
      then `cabal (new-)build foo`. The extra packages are included into the
      install plan and they are also resolved as build targets.
      
      Currently this only uses the "any valid package name" target syntax
      which means you can use `foo` but not `foo:tests` or any of the other
      variations.
      b59d1f7b
    • Duncan Coutts's avatar
      resolve package name targets to any package within the project · ec6b17b6
      Duncan Coutts authored
      That is, any package name within the install plan. This allows
      targeting a dependency of a package that is local to the project.
      ec6b17b6
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Move PackageSpecifier into common Types module · b9ce4337
      Duncan Coutts authored
      It's currently in the old Targets module, but we'll need it in the
      new-build code too soon, and it's not really that closely related to
      targets, so it makes sense to have it live in the common Types module.
      b9ce4337
    • Duncan Coutts's avatar
      Add cli target support for out-of-project package names · c6f8d1b0
      Duncan Coutts authored
      There is nothing except for syntax support, but this is a first step
      towards proper support for targets refering to dependencies or to out of
      project packages.
      
      For the moment, when used, it will report:
      
          cabal: Cannot build the package foobar, it is not in this project
          (either directly or indirectly). If you want to add it to the
          project then edit the cabal.project file.
      
      Also update the test output for an integration test.
      c6f8d1b0