GitLab

Closes: https://github.com/haskell/cabal/issues/2447

Client.Init: add ChangeLog.md to extra-source-files if necessary. If there's already a ChangeLog-like file, it won't generate ChangeLog.md.

(cherry picked from commit 66dade37)

(cherry picked from commit f445c3a3)

We need the Ord instance for URI which was added in 2.4.

Fixes #2338.

Fixes #2217.

If the compiler (e.g. GHC 7.10) supports outputting OS native debug
info (e.g. DWARF) passing --enable-debug-info[=n] to cabal will
instruct it to do so.

We need to know which version of network we installed.

Hopefully fixes #2310 for real.

Fixes #2310.

That package doesn't have any modules and Hadddock chokes.

Fixes #2241.

I think the ProgramDB API should be redesigned to prevent such
problems in the future.

for the windows clean hack.

This would cause exceptions when using a cached setup executable,
making parallel builds on Windows completely unusable.

for the windows clean hack.

This would cause exceptions when using a cached setup executable,
making parallel builds on Windows completely unusable.

Now that Cabal is in charge of RPATH handling on certain OS',
we must always setup a correct (DY)LD_LIBRARY_PATH when
running the testsuite. Not just when we are building relocatable
packages.

The "problem" is, is that Cabal now adds an RPATH pointing
to the installation location of the library. However, during
testing, the library won't be there yet. We much hence setup
a (DY)LD_LIBRARY_PATH that includes the dist/build dir.

Inside a cabal exec environment cabal should be configured to always use the
correct environment. When there is a sandbox this is addressed by setting the
CABAL_SANDBOX_CONFIG environment variable.

However GHC is configured to use the correct package database through setting
the GHC_PACKAGE_PATH environment variable to include the sandbox database. The
Cabal library previously refused to operate when GHC_PACKAGE_PATH is set in
order to avoid having a different view of the package databases to GHC.

In the case of a cabal exec environment being loaded for a cabal sandbox, it
is safe to allow the use of GHC_PACKAGE_PATH as it is being used to ensure
that GHC uses the same package database as cabal does.

A check is made that GHC_PACKAGE_PATH matches the value that cabal exec set it
to. If it does use of GHC through cabal is permitted.

Fixes #1800

This needed since Cabal requires `binary == 0.7.*` which is only
satisfied by GHC 7.8 and later.

With this, bootstrap.sh now should work for (at least) GHC 7.4 and later

As a consequence of treating all flag choices as a common goal for
conflict set computation, error message slicing was broken and did
not contain any information about flag choices anymore.

With this change, information about flag choices is once again
included in error messages.

This hopefully addresses issue #2280.

The problem was as follows: In the modular solver, manual flags are
enforced. However, in order to respect manual choices by the user,
which are still allowed, we would first check if one of the two choices
had already been disabled, and only if that's not the case, disable
the non-default choice.

However, a manual user constraint is not the only reason why the default
flag choice can be disabled at this point. It can already be disabled
in the validation phase, if it's immediately obvious to the solver at
this point that it can never work. In such a situation (which is
described in #2280), the solver would then fail to respect a manual
flag and allow to change it without user intervention.

The fix seems simple: we now explicitly check whether the flag choice
has been disabled *by the user*, and only then leave it alone.
Otherwise, we enforce the manual flag.

(cherry picked from commit 5b367e51)

(cherry picked from commit 5ff93343)