This change is for adding the ehancement to support haddock response files. This is what was used to build HP 7.10.2 for Windows, but it does need a corresponding change in haddock to utilize it. Hopefully, this and its corresponding haddock change can make it into the next ghc release and eliminate much gnashing of teeth, error prone, and time consuming manual steps in the HP build process. Modified: * Cabal/Distribution/Simple/Haddock.hs * renderArgs function: I put a couple of things into locals since I needed another use for UTF8 support check, plus I added another check based on version; the temp file logic was just as the prologue case above but I did need to repeat the invocation of the 'k' function in order to keep the cases separate and allow proper handling of the temp file automatic (or not, per --keep-temp-files) deletion. Important: the haddock version being check against for response file support, greater than 2.16.1, is a placeholder and may or may not be the actual value since that will depend on the as-yet-unreleased haddock (which looks like it may be >2.16.1 but at this moment is not released).
It wasn't used within the InstallPlan, but it had accessors and those were used in a few places. Just pass them into those few places that need it.
So rather than the concrete InstalledPackageInfo and ConfiguredPackage, the InstallPlan and PlanPackage are parameterised by the type of the installed package, the source package and the types used for successful and unsucessful build results.
Fewer shared types makes the code easier to grok and navigate.
No longer needed anywhere else.
Removed from the InstallPlan and solver interface. The InstalledPackage is really just there for the benefit of the old TopDown solver which needs to know source deps.
Rather than directly reusing the InstallPlan.PlanPackage type which has more cases and which we'd like to generalise somewhat.
The InstallPlan can be generalised by abstracting over the specific package types. The only thing that really relies on a lot of the details of the concrete ConfiguredPackage type is the bit that validates them individually (as opposed to validating packages within the plan in relation to other packages, graph structure etc). So as a prelude to generalising the InstallPlan, move the checks on the ConfiguredPackage into the Dependency module and use them when checking the output of the solver.
This fixes #2689.
Signed-off-by: Edward Z. Yang <email@example.com>