This project is mirrored from https://github.com/haskell/Cabal.
Pull mirroring updated .
- 11 Jan, 2017 1 commit
-
-
Mikhail Glushenkov authored
-
- 10 Jan, 2017 3 commits
-
-
John Ericson authored
-
John Ericson authored
Forget case of arbitrary program on PATH
-
Fixes #4214. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 09 Jan, 2017 1 commit
-
-
Rob Henderson authored
Qualified constraints (issue #3502)
-
- 08 Jan, 2017 2 commits
-
-
Robert Henderson authored
-
Robert Henderson authored
-
- 07 Jan, 2017 7 commits
-
-
Robert Henderson authored
Amended parsing and pretty-printing code of UserConstraint to handle qualifiers. Qualified constraints are now accepted on the command line, but the solver and other subsystems currently just ignore the qualifiers and don't do anything differently from before.
-
Robert Henderson authored
This eliminates some boilerplate code.
-
Robert Henderson authored
Changed PackageConstraint to PackageProperty in both cases, since the name in the PackageConstraint was redundant.
-
John Ericson authored
[WIP] implement tool-depends
-
Robert Henderson authored
Refactored PackageConstraint in two ways: 1) split it into a package name and a 'PackageProperty' to make the code a bit cleaner; 2) changed PackageName to 'Qualified PackageName'. Added a Binary instance for Qualifier in PackagePath.hs (needed for PackageConstraint). Added pretty-printing code for PackageConstraint. For now, all the code that creates a PackageConstraint just sets the qualifier to 'unqualified', so this commit will not change the external behaviour of cabal-install.
-
Robert Henderson authored
I modified the pretty-printing code so that it uses the 'Text.PrettyPrint' system rather than raw strings. I updated the syntax of pretty-printed qualifiers to use colons as separators rather than hyphens to fix an ambiguity problem (since hyphens can occur in package names). See issue 3502.
-
Rob Henderson authored
Preliminary refactoring in preparation for issue #3502
-
- 06 Jan, 2017 19 commits
-
-
John Ericson authored
`build-tools` is described in terms of `build-tool-depends`, just as it is implemented in terms of it.
-
John Ericson authored
Modeled after the extern_build_tools test
-
John Ericson authored
-
John Ericson authored
-
John Ericson authored
-
John Ericson authored
- Existing test `InternalLibrary4` was deleted because it relied on the old behavior. - New tests added are: - InternalVersions/BuildDependsBad - InternalVersions/BuildDependsExtra - InternalVersions/BuildToolsBad - InternalVersions/BuildToolsExtra - InternalVersions/BuildToolDependsBad - InternalVersions/BuildToolDependsExtra - ToolDependsInternalMissing
-
John Ericson authored
Previously: - "build-depends" entries on internal libraries with an explicit version range are an error. Now for all three of "build-tools", "tool-depends", and "build-depends": - Explicit versions ranges on internal components that are satisfied by the current package cause a warning. - Explicit version ranges on internal components are are not satisfied by the current package are an error. And additionally for "tool-depends": - dependencies on a non-existent executable in the current package are an error.
-
John Ericson authored
A lack of ":exename" is susposed to indicate all exe components of the package, but this complicates parsing so I'm punting for now: an explicit component name is required.
-
John Ericson authored
-
John Ericson authored
The goal is to deemphasize calling it "new-build" and push "Nix-style Local Builds" instead, as the former name only makes sense while the old system is the default
-
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
The recorded build-depends should be consistent with the extra metadata we created when dep-solving. No need to overwrite. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Robert Henderson authored
'flatStyle' is a rendering style for the pretty-printer that renders all on one line.
-
Robert Henderson authored
-
Robert Henderson authored
-
Robert Henderson authored
I moved these functions to GenericPackageDescription.hs, where the FlagAssignment type is defined.
-
- 05 Jan, 2017 2 commits
-
-
Robert Henderson authored
-
Robert Henderson authored
-
- 03 Jan, 2017 5 commits
-
-
Mikhail Glushenkov authored
[ci skip]
-
Mikhail Glushenkov authored
[ci skip]
-
kristenk authored
Add a comment to 'Distribution.Solver.Modular.Cycles.findCycles'.
-
kristenk authored
[ci skip]
-
A signature package is a package that contains only signatures but no modules (equivalently, it is a package that has no provisions.) Previously, we did not treat signature packages any differently from normal packages, which, in particular, meant that when we instantiated a package using a signature package, we also instantiated the signature package. This is actually pretty useless, because we never actually use the instantiated signature (there's no code that actually gets compiled in this case). This patch treats signature packages specially, so that we don't actually instantiate dependencies on them. This means we have to compile less packages when handling signatures. Good! Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-