(cherry picked from commit 66dade3)
(cherry picked from commit f445c3a)
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