GitLab

Forget case of arbitrary program on PATH

Edward Z. Yang authored Jan 06, 2017 and Edward Z. Yang committed Jan 10, 2017

Fixes #4214.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Qualified constraints (issue #3502)

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.

This eliminates some boilerplate code.

Changed PackageConstraint to PackageProperty in both cases, since
the name in the PackageConstraint was redundant.

[WIP] implement tool-depends

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.

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.

Preliminary refactoring in preparation for issue #3502

`build-tools` is described in terms of `build-tool-depends`, just as it is
implemented in terms of it.

Modeled after the extern_build_tools test

 - 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

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.

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.

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

Edward Z. Yang authored Jan 04, 2017 and Edward Z. Yang committed Jan 06, 2017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored Jan 02, 2017 and Edward Z. Yang committed Jan 06, 2017

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>

Edward Z. Yang authored Jan 02, 2017 and Edward Z. Yang committed Jan 06, 2017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored Jan 02, 2017 and Edward Z. Yang committed Jan 06, 2017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored Jan 01, 2017 and Edward Z. Yang committed Jan 06, 2017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

'flatStyle' is a rendering style for the pretty-printer that
renders all on one line.

I moved these functions to GenericPackageDescription.hs, where
the FlagAssignment type is defined.

[ci skip]

[ci skip]

Add a comment to 'Distribution.Solver.Modular.Cycles.findCycles'.

[ci skip]

Edward Z. Yang authored Dec 27, 2016 and Edward Z. Yang committed Jan 02, 2017

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>