This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 14 Jul, 2018 1 commit
  2. 13 Jul, 2018 3 commits
  3. 09 May, 2018 1 commit
  4. 27 Apr, 2018 1 commit
  5. 26 Apr, 2018 1 commit
  6. 03 Mar, 2018 1 commit
  7. 14 Jan, 2018 1 commit
  8. 09 Jan, 2018 1 commit
  9. 02 Dec, 2017 1 commit
  10. 08 Nov, 2017 1 commit
    • Duncan Coutts's avatar
      Remove reundant args of selectComponentTarget functions · b0f7a9b6
      Duncan Coutts authored
      The PackageId and ComponentName are already part of the existing
      AvailableTarget record argument.
      
      We need to eliminate this redundancy because for new kinds of target
      selectors we will not have the PackageId and ComponentName from the
      selector, only from the AvailableTarget selected.
      b0f7a9b6
  11. 05 Nov, 2017 2 commits
    • Duncan Coutts's avatar
      TargetPackage TargetSelector allows multiple package ids · 1fb24861
      Duncan Coutts authored
      That is, the TargetPackage instead of having a single PackageId contains
      a [PackageId].
      
      Ultimately this will allow us to support multiple .cabal files in a
      single directory. But the real reason to do this generalisation now is
      that it helps with the TargetImplicitCwd case. For the implicit CWD case
      we need to be able to parse the target whether or not there is a package
      in the CWD. So the simplest solution is to pass in all the local CWD
      packages (though typically only 0 or 1) and put all of them in. Then at
      the end we can check if in fact there were 0 and fail.
      
      When we do want to support multiple .cabal files in a dir, we'll also
      need to adjust the project config code, and extend the syntax slightly
      so that we render as the package location for the case of multiple
      packages.
      1fb24861
    • Duncan Coutts's avatar
      Don't paramaterise the TargetSelector type · 11872e57
      Duncan Coutts authored
      Previously the TargetSelector type had a type param for the type of the
      package that it referred to. In particular we used it with types like:
      
      type Matcher  = ... -> Match (TargetSelector KnownPackage)
      type Renderer = TargetSelector PackageId -> ...
      
      However we are about to extend the TargetSelector so that it does not
      just refer to one form of package (e.g. KnownPackage) but can refer to
      packages via various different forms and partial information. So it no
      longer makes sense to have TargetSelector be paramaterised by the
      different states of the one kind of package it refers to, as there are
      now many kinds. So in preparation for that we simplify it so that it is
      equivalent to always using TargetSelector PackageId, and we remove the
      type paramater.
      11872e57
  12. 14 Oct, 2017 1 commit
    • 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
  13. 07 May, 2017 1 commit
    • Edward Z. Yang's avatar
      Greatly reduce the amount of build product we upload. · bed3e5ca
      Edward Z. Yang authored
      
      
      See #4462 for the gory details.
      
      Main things about this commit:
      
      - New 'monolithic' flag on cabal-install, which combines
        all of the tests into a single binary.  It's not very
        much code, and you don't pay for any of it on a release
        build.  I quite like it.  The one downside is that
        we can't also pull in Cabal test suites this way.
      
      - Env vars got moved into travis-common.sh
      
      - travis-script.sh now runs the cabal-tests tests, because
        we aren't sending enough build product over to do them
        on the second Travis run
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bed3e5ca
  14. 01 Apr, 2017 1 commit
  15. 10 Mar, 2017 1 commit
  16. 09 Mar, 2017 1 commit
  17. 07 Mar, 2017 7 commits
    • Duncan Coutts's avatar
      Add integration tests for the target resolving for each command · 6ede1f2b
      Duncan Coutts authored
      This covers some of the positive cases of target selector resolution
      and pretty much all of the negative cases for each command.
      6ede1f2b
    • Duncan Coutts's avatar
      Adjust planning infrastructure in the IntegrationTests2 · 1329ec54
      Duncan Coutts authored
      Change the division between planProject and executePlan.
      
      This division will be what we need for a bunch of new tests.
      1329ec54
    • Duncan Coutts's avatar
      Simplify IntegrationTests2 using overloaded strings · 1c46df4a
      Duncan Coutts authored
      We now have IsString instances for ModuleName, PackageName,
      UnqualifiedComponentName. We also have a local instance for PackageId.
      Using these makes the test case code shorter and clearer.
      1c46df4a
    • Duncan Coutts's avatar
      Split TargetSelectorNoTargets case into two sub-cases · 5dd6a76f
      Duncan Coutts authored
      In resolveTargetSelectors we return [TargetSelectorProblem] which
      includes a case TargetSelectorNoTargets. We split this into two cases:
      TargetSelectorNoTargetsInCwd and TargetSelectorNoTargetsInProject.
      
      The latter covers the important special case when there are no targets
      in the project as a whole. The former covers the same remaining cases as
      the original.
      
      This is a useful special case since it corresponds to running commands
      in a directory where there is no .cabal files and that is not underneath
      a project. Add a hopefully useful error message for this case.
      
      Also adjust the integration tests covering this case, which now split
      into two separate cases.
      5dd6a76f
    • Duncan Coutts's avatar
      Add a number of TargetSelector tests · eb4783d4
      Duncan Coutts authored
      We already had tests covering valid syntax. This adds tests for invalid
      syntax and ambigious cases. Also cases for empty projects, or when there
      is no cwd package.
      eb4783d4
    • Duncan Coutts's avatar
      Change TargetSelector to remove TargetCwdPackage · 34e0d5cd
      Duncan Coutts authored
      Refactor so that instead of two constructors TargetPackage and
      TargetCwdPackage we have just TargetPackage with an extra bool-like field to
      distinguish the two.
      
      This simplifies things in the consumers of TargetSelector which
      typically have to treat TargetPackage and TargetCwdPackage in the same
      way.
      
      Also eliminate the list field in TargetCwdPackage. We don't yet support
      multiple .cabal files in one dir, and when we do we'll do the same for
      the cwd targets as for other explicit targets. The only annoying thing
      here is that we need to use a dummy package info value because the
      representation does not allow for not having one. The tradeoff is still
      worth it in terms of less verbose consumers.
      
      Also adjust tests.
      34e0d5cd
    • Duncan Coutts's avatar
      Add positive tests for reading target selectors · ac006b4d
      Duncan Coutts authored
      So this covers most cases that are expected to work. Still need to do
      cases that are invalid syntax, unrecognised, or ambigious.
      
      Also added a note about a bit of an inconsistency in how we treat source
      file targets.
      ac006b4d
  18. 27 Feb, 2017 3 commits
    • Duncan Coutts's avatar
      elaborate impl of findProjectRoot · 5b1eca08
      Duncan Coutts authored
      Take an extra arg to control where to start searching, not just process
      current directory. This is mainly to make it easier to test without
      having to mutate the cwd but is potentially useful generally for
      cwd-independence.
      
      Return more detailed info: not just the directory but return if it's an
      implicit or an explict project root with a cabal.project file. In the
      latter case also return the cabal.project file since its name can be
      overridden. Then also adjust defaultDistDirLayout to take this more
      detailed ProjectRoot type, thus avoiding having to duplicate the logic
      about the location of the cabal.project file.
      
      Change the behaviour so that if an explicit cabal.project file name is
      given and it is not found then fail, rather than falling back to an
      implicit project root style. This would seem to make most sense: if the
      user specifies an explict cabal.project file then it'd be odd if we
      silently ignore that if the user misspells it or something. The implicit
      root default is really for the really simple case, not when users are
      explicitly specifying stuff.
      
      Also add a couple simple tests for findProjectRoot.
      5b1eca08
    • Duncan Coutts's avatar
      Extend DistDirLayout with project root and cabal.project · 2b26e75b
      Duncan Coutts authored
      So the DistDirLayout now contains the root dir of the project as a
      whole, which eliminates the need to pass it separately in several cases.
      It also contains the location of the cabal.project file, which again
      avoids having to pass it around.
      
      In part these changes were to allow the elimination of uses of the
      legacy config types in the new-build code. The idea is that the legacy
      config types are only used by conversion into the new config types, and
      then only the new types are used in the new code.
      2b26e75b
    • Duncan Coutts's avatar
      607fe7c0
  19. 17 Jan, 2017 1 commit
  20. 27 Nov, 2016 2 commits
  21. 06 Oct, 2016 1 commit
    • Mikhail Glushenkov's avatar
      Fix CI on Mac OS X with GHC 7.8 and earlier. · 2ed454ee
      Mikhail Glushenkov authored
      
      
      On recent OS X, Cabal does not work correctly because it assumes
      that a permission denied error when reading permissions on
      executables, resulting in errors like "Setup: /usr/bin/ar: permission denied".
      
      The proximal fix for this is to add a constraint on unix when we build
      Cabal/cabal-install to avoid building with the buggy version of unix.
      But this causes other problems:
      
      - Bumping the version of unix means that our local build of Cabal
        will depend on things from the store.  But we weren't passing
        this to GHC when compiled Setup.hs for Cabal's package-tests.
        Set CABAL_PACKAGETESTS_DB_STACK env var explicitly to point
        to the right locations.
      
      - The new configuration of versions exposed some bugs in some
        macro expanded code in cabal-install; we qualified those
        imports to squash unused warnings.
      
      - The cabal-install integration-tests occasionally use Cabal from
        the system GHC.  Since this will never work on OS X, we just
        skip the tests in those cases.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2ed454ee
  22. 29 Sep, 2016 1 commit
    • Duncan Coutts's avatar
      Move improveInstallPlanWithUpToDatePackages out of rebuildTargetsDryRun · f1c84021
      Duncan Coutts authored
      Instead rebuildTargetsDryRun will just return the BuildStatusMap and
      runProjectPreBuildPhase in ProjectOrchestration will compose things by
      calling improveInstallPlanWithUpToDatePackages.
      
      This is just a slight shifting of functionality from here to there, but
      better reflects responsibilities. This is also slightly with a future
      status command in mind which likely only needs the BuildStatusMap.
      
      Also adjust the tests after changing type of rebuildTargetsDryRun.
      f1c84021
  23. 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
  24. 27 Sep, 2016 1 commit
    • 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
  25. 18 Sep, 2016 1 commit
    • Brendan Hay's avatar
      Track project configuration provenance · c2ebd714
      Brendan Hay authored
      - Excludes provenance from all roundtrip tests
      - Inserting explicit provenance when read from file
      - Special cases for bad package errors arising from
        implicit project configuration
      c2ebd714
  26. 04 Sep, 2016 2 commits
  27. 21 Aug, 2016 1 commit