GitLab

This is especially useful for passing arguments to a single test suite

Closes #4684.

At least it's not just me who is confused by the naming scheme.  `project.cabal` seems much more logical to me as it's a `cabal` file. However, cabal expects the file to be called `cabal.project`, so let's make the documentation less confusing.

This also experiments with the use of Sphinx/Pygments ABNF syntax
highlighter to express syntax/grammars in terms of ABNF code-blocks.

[skip ci]

Pass extra dirs to http transport

Disable per-component build when program coverage enabled

Thomas Tuegel authored Nov 22, 2017 and Mikhail Glushenkov committed Jan 07, 2018

Creating the test program coverage report requires the test runner to know the
build directory for the library component. If per-component builds are enabled,
this is not possible because the library is not in-scope at the same time as the
test component. The only apparent solution that does not require rethinking
per-component builds entirely is to disable it when coverage is enabled.

Resolves: #4798

Suppress per-component for build-type:configure

Remove `UnknownBuildType` from `BuildType`

This is a follow-up to #4958 which opened up the opportunity to do
this make-illegal-states-unrepresentable refactoring as well.

based on a suggestion by @ezyang

Workarounds #4548 for now.

Add cabal-doctest and idris Setup.hs as smoke tests for BC

See
https://github.com/haskell/cabal/pull/4996#issuecomment-355255426. Apparently
I forgot to cherry-pick 5797013f from
2.0 to master.

Restore BC for rewriteFile

+ a whitespace fix.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

[ci skip]

Fix #4986, and extra refactoring

Target package names

Before: pkgStanzasEnabled is initialized to an empty list and
filled in on the first pruning pass.

After: pkgStanzasEnabled is initialized to the set of explicitly
requested stanzas, and then we add more enabled stanzas as we
do "pruning" passes (a bit of a misnomer).

Why is it good?  Now we always satisfy the invariant that
the set of enabled stanzas is a superset of the set of requested
stanzas; previously, the invariant was broken up until the point
you ran pruning (which, in the case of new-configure, meant that
the invariant was always broken!)  and we were tripping over this
when attempting to render the set of configure flags for plan
display.
Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Before:
    In order, the following would be built (use -v for more details):
     - Cabal-2.1.0.0 (lib) --enable-library-profiling (first run)

After:
    In order, the following would be built (use -v for more details):
     - Cabal-2.1.0.0 (lib) (first run)
Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Previously, if you had:

  build-tool-depends: happy:happy
  build-tools: happy

This would cause an executable dependency to show up twice in exe_deps.
It turns out that this made its way all the way to cabal-install's
InstallPlan, and then broke an invariant in the install plan execution
engine.  This is the "correct" fix but the whole arrangement is a little
brittle.
Signed-off-by: Edward Z. Yang <ezyang@fb.com>