GitLab

The function is very short and the name doesn't communicate clearly what it
does.

Significantly speeds up parallel builds.

It adds a '-j N' (= 'number of jobs') option for the 'install' command, which
can be used to specify the number of concurrent workers. If possible, at most
N packages will be built concurrently.

This version of the patch is less featureful than Mikhail's version but also
rather simpler. The key difference compared to Mikhail's version is that this
version is lacking the output serialisation and the ability to tag each output
message with the task it came from. All output is interleaved. The next step
will be to make parallel builds log to files rather than the console and only
to display a summary on the console.

In addition to not having to change the output functions, the code is a bit
simpler by keep the structure of the code the same as before, rather than
splitting it into a number of concurrent tasks with channels. Instead each
task simply executes the same pattern of install actions and concurrency
limits are enforced using semaphores.

GHC and ghc-pkg package db flags changed from '*-package-conf' to
'*-package-db' in 7.5.  This commit follows the change and introduces a
version check whenever those flags are used.

It used to return Maybe, now it always gives us a PackageIndex.
This depends on an API change in Cabal-1.9.x.

Remove local copies. Also fixes a bug recently introduced
in the writeFileAtomic function, spotted by Peter Robinson.

It works by ignoring the possibility that there could be multiple
installed packages sharing the same source package Id. We just pick
the "top most" one which is usually ok. We make no attempt to check
that we are using consistent installed packages.

Update to development version of Cabal

Fixes ticket #394.

map "" to "."

and in particular for bootstrapping the Cabal lib.

The branch of cabal-install that tracks Cabal-1.4 now lives at
http://darcs.haskell.org/cabal-branches/cabal-install-0.5/

So the cabal version constraint is actually passed in.
This got lost in a previous refactoring.

It doesn't need access to the whole Packagedescription,
it only needs the the PackageIdentifier.

I introduced a subtle bug with paths when I stopped using inDir
outside of setupWrapper. It was using the current dir to find
Setup.hs rather than the target dir. That ofen works because
there's a Setup.hs in the local dir. I think it's now fixed to
always use paths relative to workingDir. As before, it invokes
the setup binary giving it the new working dir.

Now uses a single code path for both modes.

The path to the binary we're running must be accessable from
that other directory. The fix is to use currentDir </> setup

For the internal method, change to the right working dir if necessary.

or for using a diiferent initial working directory. We already
need to use a different working dir and this would allow us to
spawn multiple setup processes for parallel builds each with
their own working dir. Also, we want to be able to capture the
output of builds. At the moment our internal logging framework
is not capable of redirecting, but if we launch a process we
redirect its output to a file. This should be useful for build
reporting where we want logs for each individual package.

And tidy some imports slightly

Instead of just using the latest version we use the best version
according to the following preferences in priority order:
- the same version as cabal-install was itself built with
- the same major version number as cabal-install was built with
- a stable version of Cabal (even second digit of major number)
- the latest version

Allows us to use cabal-install to build packages where we build the
Setup.hs script using an older version of the Cabal library.
This is important for packages that claim to need an older version
and it's also pretty useful for testing.

It is important to know which version of the Cabal lib the setup
script has been built with because it affects what flags we can pass
to it. So we now store the version in dist/setup/setup.version.
If the version number changes then we rebuild the setup binary.

If we're in verbose mode then always print what we're going to
install, not just when the user specifies --dry-run.

Clearer code and a wider interface to give more control.