GitLab

Fixes #2461.

GHC generics are used to derive binary instances for types appearing
in the persistent build config, which requires GHC >= 7.2 and
binary >= 0.7. Unfortunately, GHC < 7.8 ships with binary == 0.5.*.
The missing module is Data.Binary.Generics, which we have copied from
binary-0.7.2.3 to Distribution.Compat.Binary.Generics. To provide
generic implementations for the Binary class, we also have to provide
our own implementation, which is copied from binary-0.7.2.3 to
Distribution.Compat.Binary.Class. The interface required by Cabal is
exported from Distribution.Compat.Binary. This is only done if
bootstrapping Cabal with GHC < 7.8 or if binary >= 0.7 is not available,
otherwise Distribution.Compat.Binary simply re-exports Data.Binary.

Fixes #2321.

GHC-derived compiler flavors to Distribution.Simple.GHC.Internal

`deepseq-1.4.0.0`'s major change is in the default `rnf` method
implementation (see haskell/deepseq#1 for details). However, `Cabal` isn't affected
by that, and happily compiles against the current (yet unreleased) `deepseq-1.4.0.0`.

(approved by @dcoutts)

Fixes #2130.

A NubList is a list where all elements are unique, but are maintained in
their original order. The Monoid NubList's mappend implement is just:

    NubList xs `mappend` NubList ys = NubList . nub $ xs ++ ys

which preserves NubList's required properties (ordering and unique-ness
of elements) and meets the requirements of the Monoid laws (identity,
associativity and closure).

And move to 'D.S.Utils'.

David Feuer authored Sep 27, 2014 and Mikhail Glushenkov committed Sep 27, 2014

'[drop,take]WhileEnd p' is semantically the same as 'reverse . [drop,take]While
p . reverse', but more efficient and easier to read.

Unlike GHC, Cabal will still try to find a globally consistent choice for
all package names, i.e. this does *not* implement private dependencies.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Fixes #2100.

PackageTests has its own version of getPersistBuildConfig which does not
check which version of Cabal created dist/setup-config. Now that the
LocalBuildInfo is written with Binary, this version needed to be
updated, too.

The initial support for module re-exports relied on ghc-pkg to resolve
user-specified re-exports to references to specific installed packages.
This resolution is something that can fail so it's better for Cabal to
do it during the package configure phase.

In addition, it is inconvenient in ghc-pkg to be doing this resolution,
and it just seems fishy as a design. Also, the same ModuleExport type
was being used both for user-specified source re-exports and also for
the specific re-exports in the package db.

This patch splits the type into two: one for source level, and one for
resolved ones for use in the package db. The configure phase resolves
one to the other.

One minor change: it is now possible to re-export a module defined in
the same package that is not itself exported (ie it's in other-modules,
rather than exposed-modules). Previously for modules definied in the
same package they had to be themselves exported. Of course for
re-exports from other packages they have to be exposed.

So that the 'install_from_tarball' build bot step doesn't try to use the old
1.21 snapshot that comes with GHC HEAD.

Issue #1895. `createPipe` opened handles in binary mode by default,
which mangles text encoded for the current locale. Now, `hSetEncoding`
is called on the new handles. This requires `base >= 4.2`.

GHC 7.6 still distributes by default with an old version of process, which
means that requiring the most recent version prevents GHC from properly
bootstrapping out of the box.  In this patch, we relax the version requirement
on process, disabling proper ctl-c handling when the version is not sufficiently
new.

Perhaps one problem with lowering the bound, is if someone attempts to install
Cabal out of the box on GHC 7.6, the dependency solver will prefer the old
installed version, so it is very easy to end up with a cabal-install which
doesn't have working ctl-c.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Re-exported modules allow packages to reexport modules from their
dependencies without having to create stub files.  Reexports of the same
original module don't count as ambiguous imports when module finding
occurs.  The syntax is:

    "orig-pkg" OrigName as NewName

You can omit 'as NewName', in which case it is reexported as the same
name.  Self referential aliases work too; however, they're only visible
to packages which depend on this package.

Left to future work: just provide a module name 'OrigName', where ghc-pkg
figures out what the source package is.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Fixes #1928.

Until recently we supported ancient versions of Haddock, pre v2.0.  To
support the CPP extension with such versions, cabal had to invoke the
CPP before invoking Haddock on the output.  For simplicity cabal would
invoke the CPP on all Haskell files, if any Haskell file required CPP.
However, invoking CPP on a file which does not require it can cause
build failures.

Haddock v2.0+ supports the CPP via GHC, and even automatically
preprocesses any file with the {-# LANGUAGE CPP #-} pragma. Hence we
simply need only tell Haddock to enable the CPP when the CPP is a
package level default extension.

Fixes issue #1808.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Allows to remove code copied to D.S.Utils from System.Process.Internal.

* Ensure README.md is in .cabal files.
* Remove some verbiage.
* Remove broken link to old wiki in HACKING.

It's not supported by latest test-framework. See
https://github.com/haskell/test-framework/issues/2

The test runners for exitcode-stdio and detailed tests will be separated
into their own modules. They cannot share a test runner because
'--show-details=streaming' does not make sense for detailed tests the
way they are implemented now. The detailed test runner needs to be
substantially rewritten anyway, so splitting up the test runners will
eventually accomodate that goal.

Now the 'fieldGet' function of 'FieldDescr' does the
whole pretty printing of the field. Previously only the
values have been pretty printed by 'fieldGet' and the
name of the field with the colon have been printed
in the 'PrettyPrint' module.

But this separation made it more difficult to handle the
pretty printing of fields differently, because some fields
should be just printed in one lines and others - having several
values - should be printed nested with each value on a new line.

This difference in the printing of the fields is now handled by
the 'FieldDescr' constructor functions in 'ParseUtils'.

Now the 'listField' and 'commaListField' functions create 'FieldDescr'
that nest their values and all other functions create one line
for the whole field.