Skip to content
Commits on Jan 30, 2016
  1. @23Skidoo
Commits on Jan 25, 2016
  1. @23Skidoo

    Move source files under 'src/'.

    23Skidoo committed
    Fixes #3003.
Commits on Jan 16, 2016
  1. @ezyang

    Distinguish between component ID and unit ID.

    ezyang committed
    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>
Commits on Jan 8, 2016
  1. @ezyang

    Remove same-package import lists, fixes #2835.

    ezyang committed
    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>
Commits on Dec 16, 2015
  1. @dcoutts

    Add and export a showProfDetailLevel utlity

    dcoutts committed
    To be used in cabal-install. Also use it in one place in Cabal.
  2. @dcoutts

    Add more standard derived instances, Eq, Generic and Binary

    dcoutts committed
    Most types have these already. This just adds a few more.
Commits on Oct 9, 2015
  1. @ezyang

    Implement ComponentId, replacing PackageKey and InstalledPackageId.

    ezyang committed
    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>
Commits on Jul 6, 2015
  1. @dcoutts

    Make the profiling detail level configurable with a flag

    dcoutts committed
    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).
Commits on Jan 8, 2015
  1. @ttuegel

    D.Compat.Binary: backport binary generics to binary-0.5

    ttuegel committed
    GHC generics are used to derive binary instances for types appearing
    in the persistent build config, which requires GHC >= 7.2 and
    binary >= 0.7. Unfortunately, GHC < 7.8 ships with binary == 0.5.*.
    The missing module is Data.Binary.Generics, which we have copied from
    binary-0.7.2.3 to Distribution.Compat.Binary.Generics. To provide
    generic implementations for the Binary class, we also have to provide
    our own implementation, which is copied from binary-0.7.2.3 to
    Distribution.Compat.Binary.Class. The interface required by Cabal is
    exported from Distribution.Compat.Binary. This is only done if
    bootstrapping Cabal with GHC < 7.8 or if binary >= 0.7 is not available,
    otherwise Distribution.Compat.Binary simply re-exports Data.Binary.
Commits on Jan 3, 2015
  1. @tibbe

    Add support for emitting debug info

    tibbe committed
    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.
Commits on Dec 18, 2014
  1. @luite
Commits on Dec 10, 2014
  1. @luite

    use CompilerInfo rather than CompilerId for resolving flags and

    luite committed
    path templates.
    
    CompilerInfo contains more information about the compiler than
    CompilerId, which just stores the flavour and version. In particular,
    CompilerInfo knows an AbiTag, which can be used to tell binary
    incompatible results from the same compiler apart, and detailed
    information about supported languages and extensions.
    
    Some fields in CompilerInfo may be left unknown (Nothing). This can
    be used in the future to allow partially resolving configurations
    based on supported languages or extensions.
Commits on Sep 18, 2014
  1. @ezyang

    Support module thinning and renaming Cabal-side.

    ezyang committed
    Unlike GHC, Cabal will still try to find a globally consistent choice for
    all package names, i.e. this does *not* implement private dependencies.
    
    Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Commits on Aug 30, 2014
  1. @ttuegel
Commits on Aug 20, 2014
  1. @23Skidoo

    Typos.

    23Skidoo committed
    Thanks to A. Bram Neijt (see #2045).
Commits on Aug 4, 2014
  1. @ezyang

    Implement package keys, distinguishing packages built with different …

    ezyang committed
    …deps/flags
    
    Previously, the GHC ecosystem assumed that for any package ID (foo-0.1), there
    would only be one instance of it in the installed packages database.  This
    posed problems for situations where you want a package compiled twice against
    different sets of dependencies: they could not both exist in the package
    database.
    
    Package keys are a hash of the package ID and package
    dependencies, which identify a package more uniquely than a package ID, but less
    uniquely than an installed package ID. Unlike installed package IDs, these can
    be computed immediately after dependency resolution, rather than after
    compilation.  Package keys require support from the compiler.  At the moment,
    only GHC 7.10 supports package keys (the reason is that old versions of GHC
    do a sannity check to see that the <pkg-name>-<pkg-version> stored in the
    package database matches with the -package-name embedded in an hi file; so
    the format is fixed.) We fallback to package keys == package IDs for old
    versions.
    
    Note: the ./Setup configure fallback script does not try particularly hard to
    pick consistent sets of dependencies.  If your package database is too difficult
    for it to resolve, manually provide installed package IDs or use cabal-install's
    dependency solver.
    
    Note: This patch *suspends* the reinstall check unless it would result in
    a different package, so cabal-install will now happily reinstall foo-0.1
    compiled against bar-0.2 if foo-0.1 already exists.
    
    Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Commits on Jul 16, 2014
  1. @ezyang

    Implement "reexported-modules" field, towards fixing GHC bug #8407.

    ezyang committed
    Re-exported modules allow packages to reexport modules from their
    dependencies without having to create stub files.  Reexports of the same
    original module don't count as ambiguous imports when module finding
    occurs.  The syntax is:
    
        "orig-pkg" OrigName as NewName
    
    You can omit 'as NewName', in which case it is reexported as the same
    name.  Self referential aliases work too; however, they're only visible
    to packages which depend on this package.
    
    Left to future work: just provide a module name 'OrigName', where ghc-pkg
    figures out what the source package is.
    
    Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Commits on Feb 2, 2014
  1. @23Skidoo

    Remove the BSD3 text from file headers.

    23Skidoo committed
    It's just noise that duplicates information in the 'LICENSE' file.
Commits on Oct 31, 2013
  1. @23Skidoo
Commits on Oct 7, 2013
  1. @23Skidoo
Commits on May 5, 2013
  1. @23Skidoo

    80-col violations.

    23Skidoo committed
Commits on May 4, 2013
  1. @tibbe
Commits on Oct 23, 2011
  1. @igfoo

    Rename the cabal directory to Cabal

    igfoo committed
    Makes things a little simpler in GHC's build system if libraries are in
    the same directory as their name.
Something went wrong with that request. Please try again.