An annoyance of the current Simple build system is that each phase (build, install, etc) can be passed additional HookedBuildInfo which gets merged into the PackageDescription. This means that we cannot process the PackageDescription up front at configure time and just store and reuse it later, we have to work from it each time afresh. The recent addition of Components (libs, exes, test suites) and a topoligical sort of the components in the LocalBuildInfo fell foul of this annoyance. The LocalBuildInfo stored the entire component which meant they were not updated with the HookedBuildInfo. This broke packages with custom Setup.hs scripts that took advantage of the HookedBuildInfo feature, including those with configure scripts. The solution is to store not the list of whole components but the list of component names. Then withComponentsLBI retrieves the actual components from the PackageDescription which thus includes the HookedBuildInfo. Also moved the Components into an internal module because (for the moment at least) it is part of the Simple build system, not part of the package description.
- Add a default "(none)" option for license and category. There are now no questions with no default except for the lib/exe question. For throwaway packages user can just keep hitting enter and get something sensible. - Prune the list of suggested licenses (remove unversioned GPL, LGPL) - Don't include extra-source-files or build-tools when they would be empty - Improve the wording of the generated documentation for lib/exe fields
Use slightly longer lines and a somewhat more terse comment. Also use a new shorter and hopefully stable URL for the user guide.
Users will typically only want this the first time they use cabal init.
E.g. cabal install cabal-18.104.22.168 would actually install the latest version instead, because when 'cabal' got corrected to 'Cabal' the associated constraint 'cabal == 22.214.171.124' was not converted to 'Cabal == 126.96.36.199'.
Will make tracking down problems easier in future.
e.g. --constraint='foo source' --constraint='baz installed' --constraint='bar +this -that'
…ging Now log when things get excluded due to installed and source constraints.
There are many packages that can never be successfully configured and by pruning them early we reduce the number of choices for the solver later (which is good since the solver does no backtracking when it makes bad choices). This relies on two recent features: 1. we can now express constraints that exclude a particular source package and 2. that we can exclude packages without needing to know whether or not they will ever be needed.
We now track target packages and only require constraints on those targets to be satisfiable. This allows us to overconstrain packages that we do not care about, which is useful for excluding broken packages. We also now have a more general way of specifying constraints. Previously constraints were specified as the conjunction of a version range predicate and an optional installed constraint. This form made it impossible to express constraints such as "exclude this source package". Constraints for a package name are now specified simply by a function predicate on the package version and installed/source state.