GitLab

To allow parsers & pretty-printers for extensions of the format.

And add a TODO about future handling of OS variants like Android and iOS.

It has been deprecated in ghc-7.2
and ghc builds core libs with -Werror so we have to comply.

Otherwise we cannot use '{' '}' chars in field contents, as they
get interpreted as layout syntax. We want this for things like:
  library-dirs: ${pkgroot}/../libfoo/

Fixes ticket #844. Previously the function that merged the HookedBuildInfo
into the PackageDescription would add a library section even if none
previously existed.

Now we generate an error message if the HookedBuildInfo contains info
for non-existant components (libs/exes), e.g:

Setup: The buildinfo contains info for a library, but the package does not
have a library.

As suggested by Hamish Mackenzie

Hopefully should fix ghc ticket #4982.
The problem was permissions on directories: previously we used ordinary
createDirectory and on unix this creates dirs using the current user's
umask. If the root user has a silly umask then someone doing sudo
install will end up with dirs that are not readable by non-root users.

So the solution is to do the same as we do with files: override the
umask and explicitly set the file permissions based on the kind of
file: ordinary file, executable file and now also directory.

Sadly we also had to re-implement createDirectoryIfMissing to use our
new createDirectory wrapper function.

This patch adds intrapackage dependency resolution so that components
(libraries, exes, test suites) are build in the correct order.  This mean it's
now possible to have, e.g., executables that depend on other executables defined
in the same package description: the build-tools namespace has been extended
accordingly.
  
Related to this change is the refactoring of the do-it-all preprocessSources
function, formerly invoked by initialBuildSteps, into a a function
preprocessComponent that is invoked when a component is being built.  This lets
us use executables defined in a package to be used as a custom preprocessor when
building other components.
  
Finally, a number of functions now operate on values of the sum type
PackageDescription.Component rather than specifically operating on Library or
Executable and so forth.

That is, allow generating a dir tree rather than a tarball.
Apart from being useful directly, this is the right approach for
tools like cabal-install. cabal-install does the tar step itself
and might like to do other things like zip format.
Also cleaned up the sdist code a little.

We could make this conditional, to support old GHC versions, but I
don't think it is worth the cost to support 6.8. By the time this Cabal
is released, you will need at least 6.12 (if not higher) to build the
GHC it comes with.

This enables it to be build with GHC-6.8

Ticket #811. This fixes a problem where Cabal would fail to detect the "type"
field of a test suite when the test suite contained a conditional. Conditionals
can now be used, with the restriction that the "type" field and the appropriate
"main-is" or "test-module" field must be specified together in any conditional
branch where they occur.

See ticket #792.

We now avoid calling getWindowsProgramFilesDir and
getAppUserDataDirectory when we don't need to know their results.
This means that a GHC build goes through when $HOME is unset
(GHC trac #5047).

We don't want to contaminate the hc-pkg output with info/debug messages.
Coincidentally the messages that current ghc-pkg versions produce at
-v2 verbosity level do not cause a problem. There's no reason to expect
future versions to work that way however.

Previously it returned the value [emptyInstalledPackageInfo]

The description is already included. The one-line synopsis should be
there too. Note that this is an API change that will affect compilers.

The chapter on installing packages still needs to be rewritten
to describe the cabal tool, rather than runhaskell Setup.hs

Originally Thomas had moved them to Distribution.PackageDescription
but I'm rather of the opinion that the functions (and the data
structure) that they manipluate is ugly and I'd rather keep them
hidden away in a less public module.

Now supports $pkgid, $compiler, $os, $arch, and $test-suite.