This project is mirrored from https://github.com/haskell/Cabal.
Pull mirroring updated .
- Oct 09, 2016
-
-
quchen authored
Just added the build to the list of allowed failures before, not to the actual list of things to build :-)
-
quchen authored
-
Mikhail Glushenkov authored
Adapt to changes in Distribution.Version.
-
Andres Löh authored
The DEBUG_TRACETREE debugging feature of cabal-install still had a call to 'showVersion' in it, which has been removed by recent changes to 'Distribution.Version'.
-
kristenk authored
Fix conflict counting bug
-
Mikhail Glushenkov authored
Add Distribution.Compat.DList
-
- Oct 08, 2016
-
-
Oleg Grenrus authored
-
Mikhail Glushenkov authored
D.S.GHCJS.libAbiHash: exclude trailing newline.
-
Franz Thoma authored
We used to miss a lot of conflicts during counting in `logBackjump`. Counting initial conflicts here drastically reduces search time in some cases. Not sure whether counting the current conflicts (`cs`) may be even better than counting the initial conflicts (`initial`).
-
Mikhail Glushenkov authored
-
Mikhail Glushenkov authored
Already fixed in the parent module in 20e35704. Fixes #3915.
-
This definition was both in the module, and in a CPP-conditionally imported other module. This patch removes this redundancy. In the normal Cabal build this was not an issue, since it uses a newer version of QuickCheck. The Stack-based build however still uses an old one, which lead to both the import as well as the local definition from being in the code. The testsuite would then fail with a duplicate definition error. Fixes haskell/cabal#3950
-
Mikhail Glushenkov authored
Add ModuleName.fromComponents
-
Mikhail Glushenkov authored
Fix Stack build
-
Oleg Grenrus authored
-
Oleg Grenrus authored
-
quchen authored
The hackage-security dependency in stack.yaml (0.5.2.1) is incompatible with what cabal-install requires (>=0.5.2.2). Bumping the version to that lower bound resolves the issue.
-
Edward Z. Yang authored
Pass -this-component-id to GHC when necessary.
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
You never want those packages; you want the indefinite one which you'll improve into a definite one. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
The primary consequence is that we can't assume that we have a ComponentId when we have a UnitId in hand. Most of the time, this just means we have to pass around ComponentId explicitly. No problem. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Also fix a wibble in GHC's output in this case. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Previously GHC inferred it off of -this-unit-id but we've modified things so that GHC makes no assumptions about the format of instantiated unit ids. In that case, pass it in explicitly! Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- Oct 07, 2016
-
-
Mikhail Glushenkov authored
Lower library compatibility version to 1.25, since 1.25 is dev series…
-
- Oct 06, 2016
-
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Only reregister inplace package if we built it.
-
Edward Z. Yang authored
Backpack
-
bardur.arantsson authored
Make the initial '~/.cabal/config' comment more obvious.
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
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:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-