GitLab

Otherwise we don't get links to types from packages that we don't
directly depend on.

It was still defining CABAL_VERSION=1,5,3

Also, ban rather than just warn about the -optl-Wl,-s hack
now that Cabal strips exes by default.

due to the PackageSet/Index api changes

We allow extra rgs and the location of programs to be given to
the build and haddock commands, not just at configure time. The
code to do this is now simpler and more general. This should not
be the default use mode however since it involves configuring
the programs each time where as doing it at configure time allows
it to be done once and saved. Further, specifying a different
version of the program at build time than at configure time is
likely to fail, especially for the compiler programs. Changing
the compiler really requires reconfiguring.

The haddock command now supports --haddock-options=

So we're going to allow --with-PROG for the build and haddock
commands, in addition to the existing --PROG-options= flags.

Mostly for dealing with lists of programs so that client
code doesn't need quite to much flip foldl' (flip thing)
Add specific helpers for reconfiguring programs and
restoring a full ProgramConfiguration after usign read.

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.