Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Anders Kaseorg authored May 19, 2016 and Mikhail Glushenkov committed May 19, 2016

GHC 7.8 renamed "Gcc Linker flags" to "C compiler link flags" and "Ld
Linker flags" to "ld flags"
(https://ghc.haskell.org/trac/ghc/ticket/4862

).

Without this corresponding fix in Cabal, the old-time package fails to
compile on Ubuntu yakkety amd64, where the system GCC now defaults to
-pie and GHC has

    $ ghc --info | grep -i pie
     ,("C compiler flags","-fno-PIE -fno-stack-protector")
     ,("C compiler link flags","-no-pie")
     ,("ld flags","-no-pie")

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
(cherry picked from commit c993a0c6)

Instead of computing the renamings based on componentPackageRenaming
right before it gets to GHC, compute it *during configure time*.
This will make some refactorings for Backpack easier.

NB: I had to keep componentPackageDeps because removing it would
be a big BC break.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This commit is a number of refactorings that I needed to do
while fixing bugs with internal libraries support.

- With internal libraries, it becomes especially clear that
  cabal_macros.h and Paths_foo.hs need to be done per-component.
  It is done!

  This change breaks BC in an important way: the preprocessor
  interface now takes a ComponentLocalBuildInfo along with the
  BuildInfo and LocalBuildInfo.  This means that if you implemented
  a custom preprocessor, or called 'preprocessComponent' in a custom
  Setup, you will have to make sure you pass the right
  ComponentLocalBuildInfo.  Some sub-notes:

    - While I was mucking about cabal_macros.h, I updated it to have
      two new macros: CURRENT_COMPONENT_ID (an alias for
      CURRENT_PACKAGE_KEY, but using modern terminology) and
      LOCAL_COMPONENT_ID (which refers to the public library; we use
      this in Cabal's test suite but it's unclear what the general
      utility of this is.  See the TODO.)

    - checkForeignDeps has a hack where we hardcode the
      cabal_macros.h of the main library.  If we did the foreign dep
      check for every component individually that would be better,
      but I didn't want to roll it into this patch.

- The other piece I needed for internal libraries was per-component
  install directories; otherwise, internal libraries clobber each
  other.  absoluteInstallDirs now takes a ComponentId, which is used
  to determine what '$libname' expands to.  Generally, InstallPaths
  must be computed per component, c.f. #2836.  We're not TRULY
  per-component install paths, since some files are installed for
  the "per-package" InstallPaths (the one we computed for the
  library as a whole), but for libraries we have to compute
  InstallPaths for each one.

    - While doing this, ComponentLocalBuildInfo grew a new
      'componentId' field for non-library things.  This lets us
      treat InstallPaths expansion uniformly.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

It's used as an ID. Fixes #3145.

For example, we used to search for "ld" when the program name specified by 'ghc
--info' was "i386-unknown-linux-ld".

Fixes #3140.

Fixes #3003.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

GHC 8.0 is switching the state sponsored way to specify
linker names from -this-package-key to -this-unit-id, so
it behooves us to use the right one.  But it didn't make
much sense to pass ComponentIds to a flag named UnitId,
so I went ahead and finished a (planned) refactoring
to distinguish ComponentIds from UnitIds.

At the moment, there is NO difference between a ComponentId
and a UnitId; they are identical.  But semantically, a
component ID records what sources/flags we chose (giving us enough
information to typecheck a package), whereas a unit ID records
the component ID as well as how holes were instantiated
(giving us enough information to build it.)  MOST code
in the Cabal library wants unit IDs, but there are a few
places (macros and configuration) where we really do
want a component ID.

Some other refactorings that got caught up in here:

    - Changed the type of componentCompatPackageKey to String, reflecting the
      fact that it's not truly a UnitId or ComponentId.

    - Changed the behavior of CURRENT_PACKAGE_KEY to unconditionally
      give the compatibility package key, which is actually what you
      want if you're using it for the template Haskell trick.  I also
      added a CURRENT_COMPONENT_ID macro for the actual component ID,
      which is something that the Cabal test-suite will find useful.

    - Added the correct feature test for GHC 8.0 ("Uses unit IDs").

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Backpack is going to have to rewrite this functionality.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Instead of qualifying, in some cases I just added an extra
'hiding' pragma to squelch errors.  Common conflicts
(just grep for hiding):

    - Flag
        - Distribution.Simple.Compiler
        - Distribution.PackageDescription
        - Distribution.Simple.Setup
    - installedComponentId
        - Distribution.Package
        - Distribution.InstalledPackageInfo
    - doesFileExist
        - Distribution.PackageDescription.Check
    - instantiatedWith
        - I renamed the field in InstalledPackageInfo.  But
          it's probably going away with Backpack bits; I
          migth just excise it soon.
    - absoluteInstallDirs and substPathTemplate
        - Distribution.Simple.InstallDirs
        - Distribution.Simple.LocalBuildInfo

I fixed some shadowing errors by renaming local variables in some cases.
Common shadowings (we should perhaps consider not using these as
method/field names):

    - freeVars
    - components
    - noVersion
    - verbosity
    - get
    - description
    - name

Some data structures were moved around (IPIConvert and ABIHash)
to make it easier to handle import lists.

Some functions in Utils could be turned into reexports of standard
library functions.

No explicit imports were removed from non-Cabal imports.  These
imports help maintain warning cleanliness across versions of GHC,
so I don't recommend removing them.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This is to allow monitoring programs for changes. The combination of the
location where the program was found, and all the other locations where
the program was looked for gives the full set of files to monitor for
changes in that program.

The Program programFindLocation method is extended to return the
locations looked at but where the prog was not found. The default
implementation of programFindLocation, findProgramOnSearchPath, is
extended to return those locations.

Other places have to change, mostly just the type. In a couple places in
GHC & GHCJS where there is additional searching done, the not-found
locations have to be collected and returned.

It provides a way to find out what files need to be monitored to detect
changes in a compiler's package database.

This is not used within the Cabal lib.

This refactoring allows to drop `{-# LANGUAGE CPP #-}` from a couple of
modules again.

Today in Cabal, when you build and install a package, it is
uniquely identified using an InstalledPackageId which is computed
using the ABI hash of the library that was installed.  There
are few problems with doing it this way:

    - In a Nix-like world, we should instead uniquely identify
      build products by some sort of hash on the inputs to the
      compilation (source files, dependencies, flags).  The ABI
      hash doesn't capture any of this!

    - An InstalledPackageId suggests that we can uniquely identify
      build products by hashing the source and dependencies of
      a package as a whole.  But Cabal packages contain many components:
      a library, test suite, executables, etc.  Currently, when
      we say InstalledPackageId, we are really just talking about
      the dependencies of the library; however, this is unacceptable
      if a Cabal package can install multiple libraries; we need
      different identifiers for each.

    - We've also needed to compute another ID, which we've called
      the "package key", which is to be used for linker symbols
      and type equality GHC-side.  It is confusing what the distinction
      between this ID and InstalledPackageIds are; the main reason
      we needed another ID was because the package key was needed
      prior to compilation, whereas the ABI hash was only available
      afterwards.

This patch replaces InstalledPackageId and PackageKey with a
new identifier called ComponentId, which has the following
properties:

    - It is computed per-component, and consists of a package
      name, package version, hash of the ComponentIds
      of the dependencies it is built against, and the name
      of the component.  For example, "foo-0.1-abcdef" continues
      to identify the library of package foo-0.1, but
      "foo-0.1-123455-foo.exe" would identify the executable,
      and "foo-0.1-abcdef-bar" would identify a private sub-library
      named bar.

    - It is passed to GHC to be used for linker symbols and
      type equality.  So as far as GHC is concerned, this is
      the end-all be-all identifier.

    - Cabal the library has a simple, default routine for computing
      a ComponentId which DOES NOT hash source code;
      in a later patch Duncan is working on, cabal-install can
      specify a more detailed ComponentId for a package
      to be built with.

Here are some knock-on effects:

    - 'id' is a ComponentId

    - 'depends' is now a list of ComponentIds

    - New 'abi' field to record what the ABI of a unit is (as it is no longer
      computed by looking at the output of ghc --abi-hash).

    - The 'HasInstalledPackageId' typeclass is renamed to
      'HasComponentId'.

    - GHC 7.10 has explicit compatibility handling with
      a 'compatPackageKey' (an 'ComponentId') which is
      in a compatible format.  The value of this is read out
      from the 'key' field.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This parameter was a legacy when GHC depended directly on
Cabal; this is no longer the case so there is no need for
this parameter (which is unused inside Cabal.)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This parameter was a legacy when GHC depended directly on
Cabal; this is no longer the case so there is no need for
this parameter (which is unused inside Cabal.)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This reverts commit bd7bbd70, reversing
changes made to d8fa4618.

This fixes #2689.

In GHC 7.10, Cabal always generate package keys, including in
cases where Backpack was involved (e.g. --instantiated-with).
In fact, in these case, GHC needs to be able to generate the
package key (because it will often make a substitution on the
instantiation, and needs to know if this identity coincides with
anything else we've seen previously).

Thus, we introduce a new notion, the 'LibraryName', which
is JUST the non-Backpack portion of a package key.  For ordinary
packages that are definite, a 'LibraryName' is simply
the 'PackageId' plus 'PackageKey'; for indefinite Backpack packages,
when a package gets instantiatied, it may end up with different
'PackageKey's even though the 'LibraryName' stays the same.
'LibraryName's can be computed purely by Cabal.

This patch:

    - Defines library name, which are the source package ID plus
      a hash of all the source package ID and the library names of external,
      textual dependencies,

    - Redefines the package key to be JUST the hash portion of a
      library name, in the case that Backpack is not used,

    - Records the library name in InstalledPackageInfo.

Note: the source package ID is included both externally (so the library
name is a useful handle to refer to package) and internally (so the
hash can stand alone as the package key.)

A major refactoring which is part of this commit is moving package keys/library
names from LocalBuildInfo to LibComponentBuildInfo.  If you have an LBI, you can
still extract a package key/library name using the new
localPackageKey/localLibraryName function (which looks through the
ComponentBuildInfos of a LocalBuildInfo for the library in question).  This is
conceptually cleaner for two reasons:

    1. Only dependencies of the *library* are counted as part
    of the library name, as opposed to *all* dependencies which
    we previously used.

    2. A library name doesn't really mean much for an executable,
    or a test suite, since no one else will have to link against
    them.  So we can fall back on something simpler.

A more minor refactoring is the 'LibraryName' type, which was
previously defined by LocalBuildInfo and generally looked something
like "HSprocess-0.1-XXXX".  We change the meaning of 'LibraryName'
to be "process-0.1-XXXX" (thus we have to insert some HS additions
in the code) and eliminate componentLibraries, thus assuming that
there is only ONE Haskell library (which was the case.)  So
we remove a little bit of generality and in return get code
that is much easier to read.  (The only downside is GHC's hack
to split DLLs into multiples has to be adjusted slightly, but
this is not a big price to pay.)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

New flags: --profiling-detail and --library-profiling-detail.
When profiling is enabled (by the existing flags) then these flags
are taken into account to set the profiling detail level.

The levels are:
 none
 default
 exported-functions
 toplevel-functions
 all-functions

The default value for ghc for libraries is exported-functions and
for exes is toplevel-functions.

On GHC these levels correspond to the -fprof-auto* flags. The
ghc-prof-options will override this (just because it's passed to
ghc at the end).

GHC hands us a String which we previously tried to parse as a [String],
causing GHC's compiler flags to be ignored.

We map all --enable-debug-info=n to -g in GHC.

If the compiler (e.g. GHC 7.10) supports outputting OS native debug
info (e.g. DWARF) passing --enable-debug-info[=n] to cabal will
instruct it to do so.

Inside a cabal exec environment cabal should be configured to always use the
correct environment. When there is a sandbox this is addressed by setting the
CABAL_SANDBOX_CONFIG environment variable.

However GHC is configured to use the correct package database through setting
the GHC_PACKAGE_PATH environment variable to include the sandbox database. The
Cabal library previously refused to operate when GHC_PACKAGE_PATH is set in
order to avoid having a different view of the package databases to GHC.

In the case of a cabal exec environment being loaded for a cabal sandbox, it
is safe to allow the use of GHC_PACKAGE_PATH as it is being used to ensure
that GHC uses the same package database as cabal does.

A check is made that GHC_PACKAGE_PATH matches the value that cabal exec set it
to. If it does use of GHC through cabal is permitted.

Fixes #1800

GHC-derived compiler flavors to Distribution.Simple.GHC.Internal