GitLab

That's already done by the Program framework so we were passing
those extra args in twice.

Have just a single module that provides both the case sensitive and
insensitive operations. Turns out we hardly use the case insensitive
operations, and the places where we do are not performance sensitive
at all. So we use the PackageSet implementation which stores the
packages case sensitively and tack on the case insensitive operations
but with linear time implementations rather than log time. For the
merged module/type name use PackageIndex because that is what older
released versions exported, so less needless client breakage.

Windows has restrictions on names of files and portable
tar archives have some weird length restrictions too.
Not yet used but should be used in sdist and hackage.

The installed wrapper needs to call the executable in its final place,
not inside the DESTDIR where we are constructing a package.

The immediate use for these is so that, in haddock, we can require
ghc-paths normally, but in the GHC build we can manually turn off a flag
so that this dependency isn't needed. We can't use a normal flag, or
in the normal build Cabal would infer that the flag needs to be turned
off if ghc-paths isn't available.

At least for the purposes of distribution. So if you're on unix
then you can call your package 'LPT1' if you feel you must, but
you cannot distribute a package with this name.

The InstallDirs is a separate type so it's handy to have the
command line and config file options for it available
separately. It'd be useful in cabal-install for one thing.

It's more consistent with the other flag names for dirs.
Kept the old name too, but it's not shown by --help.

Credit to Spencer Janssen. This is just a slight alternative
to the fix he proposed. It simplifies prepareSnapshotTree.

This has no effect with GHC 6.9, and with earlier GHC's it was a
misuse of cc-options.

cc-options is for options to be passed to C compilations in the
current package.  If we propagate those options to the
InstalledPackageInfo, they get passed to C compilations in any package
that depends on this one, which could be disastrous.  I've seen
cc-options like these:

   cc-options:      -optc-std=c99
   cc-options:         -D_FILE_OFFSET_BITS=64
   Cc-options:      -Wall

these are all clearly intended to be local, but are in fact currently
propagated to all dependent packages.

At request of gwern who found that it was driving him nuts.

We need to catch IO exceptions for things like "couldn't find the program",
but we also need to catch exit exceptions as Cabal uses them to signal
what the program returned.

Write a file but only if it would have new content.
If we would be writing the same as the existing content
then leave the file as is so that we do not update the
file's modification time.

We don't expect Windows systems to have the strip program anyway.

Since we tend to pass them around together rather a lot.
Also add a Text instance with a format like "i386-linux"

Now when using CPP you get 

   MIN_VERSION_<package>(A,B,C)

for each <package> in build-depends, which is true if the version of
<package> in use is >= A.B.C, using the normal ordering on version
numbers.

This is done by auto-generating a header file
dist/build/autogen/cabal_macros.h, and passing a -include flag when
running CPP.

This make "make" work even if Makefile.local contains any targets.

Does not implement lazy parsing of the output of ghc-pkg dump, so this
is only a partial fix of #311.
  
For more information about why we want to use ghc-pkg dump, see GHC
ticket #2201.