GitLab

For Hugs, nhc98 and other compilers we do not know what packages are
already installed, so we just make some up, pretend that they do exist
and just hope for the best. We make them up based on what other package
the package we're currently building happens to depend on.
See inventBogusPackageId. Let's hope they really are installed... :-)
One could see this as all rather redundant - carefully making up bogus
information to satisfy a careful check. I prefer to see it as making
explicit something that was previously implicit. The proper solution is
to discover what packages are currently installed.

This should fix ticket #120 in future which is the problem where you do
something like "sudo runghc Setup install" and you accidentally end up
using a different version of the compiler or of the Cabal lib and you get
an unhelpful error message:
> Setup.hs: error reading ./.setup-config; run "setup configure" command?
Well now you'll get a helpful error message:
> setup: You need to re-run the 'configure' command. The version of Cabal
> being used has changed (was Cabal-1.3.6, now Cabal-1.3.7).
If the compiler version being used has changed too we get the extra helpful:
> setup: You need to re-run the 'configure' command. The version of Cabal
> being used has changed (was Cabal-1.3.6, now Cabal-1.3.7). Additionally
> the compiler is different (was ghc-6.8, now ghc-6.9) which is probably
> the cause of the problem.
Of course this does not help for older versions of Cabal but there's not a
lot we can do about that.

Rather than just using a string. This makes comparing OSs easier since
we can normalise them once when we parse rather than every time we compare.
Also makes it easy to discover when a package mentions an unknown OS since
it's marked as Other "whatever".

So we use ordinary read/writeFile for ordinary text files. For console
output we use ordinary putStr etc and we'll just hope that haskell
implementations catch up and deal with that sensibly. Don't assume
captured program output is UTF8, use the default encoding.
So we use binary mode IO along with UTF8 encoding and decoding only for 
file types that we specify to be UTF8, which are .cabal files and
.hs/.lhs files only.

Added readTextFile and writeTextFile which use UTF8. rawSystemStdout now
assumes the programs are producing output in UTF8 encoding.

It uses the renaming trick to make the write atomic.
Not yet tested on Windows.

rather than [PackageIdentifier]

Add a class for packages with fixed deps, like InstalledPackageInfo and
generalise the few functions that used PackageIndex InstalledPackageInfo
specifically to use PackageFixedDeps pkg => PackageIndex pkg
This will be helpful in cabal-install for configured but not-yet-installed
packages.

New Package class of things that can be identified by a PackageIdentifier
so that covers at least PackageIdentifier, PackageDescription and
InstalledPackageInfo. Most PackageIndex operations work for any package type.

So now all the info about installed packages is available to all the
verious build phases.

We now check for packages that are broken due to their dependencies having
been unregistered. We fail and print a fairly sensible message in this case.
We also check for inconsistent dependencies and give a warning saying which
packages are depending on inconsistent versions of a third. This is a warning
not an error because it does not always lead to failure. Hopefully it'll help
people who are otherwise just running into random compile errors.
This fixes ticket #220.

The new index module is adapted from the similar module in cabal-install but
with renamed functions and extended to work with full InstalledPackageInfo
rather than just PackageIdentifier. So the getInstalledPackages functions now
return an InstalledPackageIndex.

We changed to require ghc >= 6.4 a while ago, this is just a simplification
that was missed at the time.

Have to define it locally since it only appeared in Data.List recently.

rather than just PackageIdentifier. This will enable us to do lots more in
future, for example detecting inconsistent package depends, doing our
own cpp pre-processing or module chasing.

The program prefix and suffix have been moved out of InstallDirs so that InstallDirs is now all directories.  The prefix and suffix have been moved into LocalBuildInfo as stand-alone PathTemplate flags.

And rename from QA so we no longer pretend to assure anything :-)
We now distinguish different kinds of tests with a PackageCheck type so the
caller gets to decide which kinds of checks are relevant to the context.
This PackageCheck type should be extensible if we want to add more kinds or
more info besides a brief human readable explanation.

and fix up remaing imports.
hcOptions is back in the PackageDescription module but with a different type.
GenericPackageDescription now derives Show as having the separate pretty
printer is inconvenient and in any case it is incomplete.

New Distribution.Simple.BuildPaths module similar to the .InstallDirs module
to hold all the paths and filenames used during a build.
It's currently somewhat of a miscellaneous collection.

Previously --user and --global didn't mean what it looks like they mean,
instead of doing a per-user or a global installation they just meant to
register in the per-user or global package databases (and to allow
dependencies to be satisfied from the per-user or global db)
With this patch --user / --global means to do a per-user or global install
so in addition to the package db differences it also sets the default 
installation prefix. This prefix can of course still be overridden using the
--prefix= flag. The global prefix is as before, the default per-user prefix
is $HOME/.cabal on Unix and on Windows it's something like:
C:/Documents And Settings/$user/Application Data/cabal
(using getAppUserDataDirectory "cabal"). This is the per-user prefix that
cabal-install currently uses. We can change it if people think it's not good.

but make it do something sensible with the ProgramConfiguration

And specify command flags in a way that allows converting from or two strings.
So not only can we parse command lines into the various flag types, we can
convert back. This is crucial in cabal-install so that we can call Setup.hs
scripts with all the various args, and override certain flags in a typed way
rather than just representing them all as strings.

So instead of 10 fields like this:
configPrefix   :: Maybe FilePath,
...
we have just one compound one:
configInstallDirs   :: InstallDirs (Maybe FilePath)
Now that LocalBuildInfo and cabal-install's config use InstallDirs it makes
converting a lot easier since we can use fmap and combineInstallDirs.
This should also be easier to maintain as it has significantly reduced the
number of places in the code you have to change when you add/change a dir.

This simplifies things and makes it a bit more versatile since
we can use things like InstallDirs (Maybe PathTemplate).

Since it really only refers to haddock interfaces, so interface is too
general a term. Cannot push to 1.2 branch as it changes the api.

Useful in Setup.hs scripts for things like HSQL that need to
find CC and LD flags by calling foo-config style programs.
The same function is used internally for pkg-config support.

rather than using the flag extension mechanism.
It was the old flag using it and I'm about to replace that whole system.

bug #178

See GHC bug #1372
This is a consistency check, intended to prevent this class of build
failures:

   * Package P is updated, its version number is bumped, the
     new version is compiled and installed.

   * Package Q depends on P.  Q is modified to use the new P, and Q's
     .cabal file is updated with changes to the build-depends field to
     depend on the new version of P.

   * The user has an old build of Q.  They pull the changes to Q and
     'setup build' without cleaning or re-configuring.  Build errors
     ensue, because the code of Q depends on changes to P's API, and
     we're still building against the old P.

Note that you can't get segfaults this way, only build errors.

This also relies on some new consistency checking in GHC 6.8 to work
properly.  If the user re-configures their Q build and then issues
'setup build' without cleaning, GHC must now realise that the package
flags have changed, and re-compile all the affected Q modules.  GHC
6.6 would not do this, but 6.8 does.

We previously had this kind of code all over the place:
> when (verbosity >= verbose)
>      (putStrLn "some message")
We now replace that with:
> info verbosity "some message"
Much nicer.

And fill out the includeDirs, extraLibs, extraLibDirs, ccOptions and ldOptions
with the results from pkg-config --cflags --libs