GitLab

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)

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.

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

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.

(mistakenly got removed when restructuring)

path templates.

CompilerInfo contains more information about the compiler than
CompilerId, which just stores the flavour and version. In particular,
CompilerInfo knows an AbiTag, which can be used to tell binary
incompatible results from the same compiler apart, and detailed
information about supported languages and extensions.

Some fields in CompilerInfo may be left unknown (Nothing). This can
be used in the future to allow partially resolving configurations
based on supported languages or extensions.

- previously, runCommands internally modified the description
  by adding the list of commands.
- now, globalCommands is a function that builds the complete
  description without need for changes during runCommands invocation.
- slightly more code duplication, but better separation of concerns

There's no chrome here, but some of the guts for Cabal supporting compiling
signatures.  The key UI is a new --instantiate-with flag for ./Setup (no support
cabal-install side!) which properly modifies the package key, calculates extra
hole dependencies for a package, and ensures an appropriately
translated -sig-of is passed to GHC.  The UI here is supremely user-unfriendly:
the intent is that users will use cabal-install to calculate these parameters
for them.

ToDo: Cabal's inconsistency check in ./Setup needs to be adjusted to be
less zealous.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Fixes #1884. See code comments for more details.