This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 06 Oct, 2016 7 commits
  2. 02 Oct, 2016 2 commits
  3. 30 Sep, 2016 1 commit
  4. 29 Sep, 2016 2 commits
    • Herbert Valerio Riedel's avatar
      Move ShortText to Distribution.Utils.ShortText to avoid cycles · e204a346
      Herbert Valerio Riedel authored
      This moves `String`/UTF8 conversion helpers to Distribution.Utils.String
      e204a346
    • Duncan Coutts's avatar
      Adjust behaviour of reportBuildFailures · 4d308c04
      Duncan Coutts authored
      Make sure it consistently uses stderr, rather than a mixture of stdout
      and stderr. Also rename it to dieOnBuildFailure to make it clear that
      it is fatal in the case of build failures.
      
      In general we report build failures in two steps: header plus build log
      for each failing package, then a final die exception with summary.
      Previously the build log step was reported to stdout whereas the die
      exception message gets reported to stderr. So we switch that to use
      new dieMsg and dieMsgNoWrap utils so that it all goes to stderr. Also,
      like die, these are reported irrespective of the verbosity.
      
      This is more or less just a workaround for the fact that we do not yet
      have a nice structured/formatted error mechanism that would allow us to
      throw just the one error in this case.
      4d308c04
  5. 28 Sep, 2016 2 commits
    • Herbert Valerio Riedel's avatar
      Add `Distribution.Simple.Utils.ShortText` type (#3898) · 993d20a2
      Herbert Valerio Riedel authored
      This implements a type with a compact representation of `[Char]`.
      
      The data is stored internally as UTF8 in an 'Data.ByteString.Short.ShortByteString'
      when compiled against `bytestring >= 0.10.4`, and otherwise in a
      plain old `[Char]`.
      
      `ShortByteString` is available only from `bytestring` 0.10.4 on, and GHC
      7.8.4 was the first GHC to bundle `binary-0.10.4`. So this fallback
      affects mostly only GHC 7.6 and older.
      
      Note: Originally a strict `ByteString` was used as fallback for this patch. However, the 
      `[Char]` fallback avoids pinned memory and may be more preferable when dealing with
      many small `ShortText`s
      993d20a2
    • 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
  6. 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
  7. 22 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Update default-language & avoid default-extensions (#3880) · f87738df
      Herbert Valerio Riedel authored
      This upgrades the `default-language: Haskell98` to `Haskell2010`
      and removes `default-extensions: RankNTypes, FlexibleContexts`
      in favor of adding `LANGUAGE` pragmas where needed.
      
      Moroever, this also drops `LANGUAGE` pragmas which have become redundant
      due to `Haskell2010` (specifically, `EmptyDataDecls`,
      `ForeignFunctionInterface` and `PatternGuards`)
      
      Finally, an `other-extensions` specification is put in place for the
      `Cabal` library component.
      
      This helps loading up files directly in GHCi, such as e.g. `ghci Setup.hs`
      without having to specify `-X...` flags.
      f87738df
  8. 19 Sep, 2016 2 commits
    • Edward Z. Yang's avatar
      Never use --enable-profiling when invoking Setup. · bf3d3e68
      Edward Z. Yang authored
      
      
      In Cabal 1.22.5.0, the semantics of
      --disable-profiling/--enable-profiling depend on ordering (because there
      is a hack that operates by looking at the current flag assignment and
      doing something). In particular, if I specify --enable-library-profiling
      --disable-profiling, I end up with library profiling DISABLED.
      
      The fix is that we NEVER pass --enable-profiling or --disable-profiling
      to Cabal. At the moment, and according to my historical analysis, Cabal
      ONLY uses configProf to affect the effective library/executable
      profiling, which means that anything we do with --enable-profiling, we
      can do using the library/executable profiling individually. Since these
      are always flags for the versions of Cabal library we support, we will
      get order invariance. Historical versions have varied on whether or not
      setting executable profiling implies library profiling, but if we set
      both explicitly this change in behavior doesn't matter.
      
      This patch is difficult to test because the bad profiling flags
      can't be induced on an inplace build.  I tested by hand by building
      a package that depended on 'distributive' by hand.
      
      Fixes #3790.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bf3d3e68
    • Edward Z. Yang's avatar
  9. 18 Sep, 2016 3 commits
    • Edward Z. Yang's avatar
      Use enabledBuildInfos rather than allBuildInfo. · b17a45e9
      Edward Z. Yang authored
      
      
      In many places, we incorrectly used allBuildInfo, which
      returns all BuildInfos that are buildable, and not
      necessarily the ones we are actually going to *build*.
      This used to "mostly do the right thing" because we
      literally edited the PackageDescription to nub out things,
      so you wouldn't see non-enabled components anyway.  However
      when I added support for per-component configure, I stopped
      editing the PackageDescription, which meant all of these
      uses were wrong.
      
      So, I updated them to do the right thing. Note that there
      are still uses of allBuildInfo in Check, but that probably
      requires a closer look.
      
      Fixes #3847.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b17a45e9
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Refactor ComponentEnabledSpec into ComponentRequestedSpec. · d03fe594
      Edward Z. Yang authored
      
      
      In the previous documentation for 'ComponentEnabledSpec', I claimed
      that enabled components were buildable, as well as requested
      by the user.  In the course of working on #3847, however,
      I realized that I hadn't actually *checked* that the component
      was buildable anywhere.  In particular, the 'ComponentDisabled'
      reason was *never used*.  This mostly didn't cause problems,
      however, because when we 'flattenPD' all non-buildable components
      get deleted, so you basically never actually have a non-buildable
      'Component'.
      
      But it still seemed a bit silly, so I fixed it by doing this:
      
      1) I introduce a new concept of a component being requested,
      which captures the use of --enable-tests and friends.  This
      does NOT imply buildability.  Renamed ComponentEnabledSpec
      to ComponentRequestedSpec
      
      2) A component is enabled if it is requested and buildable.
      If you give me a Component and a ComponentRequestedSpec I
      can tell you if it's enabled.  However, if you give me a
      ComponentName I can't, because I have no idea if it's buildable.
      
      3) Stopped reexporting ComponentRequestedSpec from
      Distribution.Simple.LocalBuildInfo
      
      4) Added a test for attempting to specify a non-buildable
      component as a target.  The test is accepting suboptimal
      output at the moment, see #3858.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d03fe594
  10. 11 Sep, 2016 2 commits
    • Lennart Kolmodin's avatar
      Only use portable isAbsolute/isRelative when we have to. (#3822) · 1b0560c6
      Lennart Kolmodin authored
      Only use the platform independent heuristics when we have to.
      Also rename the functions to isAbsoluteOnAnyPlatform and isRelativeOnAnyPlatform
      to make the distinction clearer.
      1b0560c6
    • ttuegel's avatar
      Revert "Respect GHC_PACKAGE_PATH" · 9c14b642
      ttuegel authored
      This reverts commit e7d2a62c due to a
      bug.
      
      The package databases obtained from GHC_PACKAGE_PATH should be stored in
      the LocalBuildInfo and passed to GHC when necessary; otherwise, the user
      could change GHC_PACKAGE_PATH causing GHC and Cabal to see inconsistent
      installed package sets. cabal-install should trigger reconfiguration if
      GHC_PACKAGE_PATH changes.
      9c14b642
  11. 10 Sep, 2016 1 commit
    • ttuegel's avatar
      Add `reconfigure` command · ae59bb3d
      ttuegel authored
      Fixes #2214 by adding a `reconfigure` command and invoking it whenever
      necessary. The last configure flags used are saved in a
      version-independent format so it should never be necessary for the user
      to reconfigure manually.
      ae59bb3d
  12. 09 Sep, 2016 2 commits
    • Lennart Kolmodin's avatar
      isAbsolute fix for Windows. · 7a8062b9
      Lennart Kolmodin authored
      The comment ending in \ turned the subsequent line of code
      into a comment. This is due to the CPP language extension which is
      turned on for this module.
      Thus the 'isAbsolute' function failed to detect absolute
      file paths on the form of DRIVE:\\PATH.
      7a8062b9
    • Lennart Kolmodin's avatar
      Use the platform independant isAbsolute/isRelative. · e46ed9e2
      Lennart Kolmodin authored
      Move the isAbsolute and isRelative to the Utils module.
      Use them throughout Cabal instead of the versions System.FilePath.
      e46ed9e2
  13. 08 Sep, 2016 2 commits
    • Edward Z. Yang's avatar
      Provide useful call-stacks over all IO code. · 48a0d6ce
      Edward Z. Yang authored
      
      
      The key idea is that we define:
      
          type IO a = HasCallStack => Prelude.IO a
      
      and voila, call stacks are maintained across all IO!  You can
      look at the stacks using -v"debug +callstack".
      
      There are a number of IO functions for which the call stack is
      never used.  They are explicitly annotated using NoCallStackIO.
      Maybe some day they will use call stacks and we can change their
      types.  Similarly, there are a number of functions which do
      have type IO, but then suppress the redundant constraint error
      using "_ = callStack". Maybe some day we will attach call
      stacks to the exceptions we throw.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      48a0d6ce
    • Edward Z. Yang's avatar
      Add support for extended verbosity specification -v"debug +callsite" · 83c93c10
      Edward Z. Yang authored
      This patch uses CallStack support in GHC 7.10 and GHC 8.0 to make
      it possible to get stack traces when we log output.
      
      This is the bare minimum to make this patch useful: there is
      plenty of tuning that can be done.  For example:
      
      * Insertions of withFrozenCallStack can help make the "callsite" output
        more useful, though be careful, we lose all stack information at that point!
      
      * Insertions of 'WithVerbosity', which will let us get deeper stacks
        (at the moment, they are basically always 1-deep.)
      
      Fixes #3768.
      
      CC @23Skidoo
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      83c93c10
  14. 06 Sep, 2016 12 commits