This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 18 Sep, 2016 1 commit
  2. 26 Jul, 2016 2 commits
  3. 29 Mar, 2016 1 commit
  4. 30 Jan, 2016 1 commit
  5. 25 Jan, 2016 1 commit
  6. 16 Jan, 2016 2 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Distinguish between component ID and unit ID. · ef41f44e
      Edward Z. Yang authored
      
      
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      ef41f44e
  7. 08 Jan, 2016 1 commit
    • Edward Z. Yang's avatar
      Remove same-package import lists, fixes #2835. · 639cd007
      Edward Z. Yang authored
      
      
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      639cd007
  8. 16 Dec, 2015 6 commits
    • Duncan Coutts's avatar
      Add a comment to explain the HcPkg.recache trick · 3761cf4e
      Duncan Coutts authored
      For supporting multi instance registrations on older GHC versions.
      3761cf4e
    • Duncan Coutts's avatar
      Add new HcPkg.registerMultiInstance · 7b4df7e0
      Duncan Coutts authored
      This supports the feature of newer ghc-pkg version which have the
      register --enable-multi-instance flag. This allows registering multiple
      instances of the same version of a package into a single database.
      
      In addition, to support the same feature on some older ghc-pkg versions,
      the HcPkgInfo has a recacheMultiInstance capability, which tells us if
      the trick of registering multiple instances by running ghc-pkg recache
      works. This is known to work for all versions of ghc-pkg that support
      the recache command at all.
      
      Then HcPkg.registerMultiInstance will use one of the two methods
      depending on which is supported, or fail if neither is. Currently only
      registering into specific package dbs is supported, not global or user.
      
      This new multi-instance feature is needed for cabal-install.
      7b4df7e0
    • Duncan Coutts's avatar
      Add internal support for hc-pkg recache and --enable-multi-instance · ae78ae05
      Duncan Coutts authored
      Invocation support but not used yet.
      ae78ae05
    • Duncan Coutts's avatar
      Extend HcPkgInfo for mulit-package instances capabilities · 728fdcf7
      Duncan Coutts authored
      Part 1: just add the fields and fill them in for each HcPkg user.
      728fdcf7
    • Duncan Coutts's avatar
      Factor impl of registerInvocation' slightly · b54f36a7
      Duncan Coutts authored
      Prior to further extension. Just share the common args calculation.
      b54f36a7
    • Duncan Coutts's avatar
      Extend HcPkg.init support for dir-style package dbs · 12b222af
      Duncan Coutts authored
      The HcPkgInfo useSingleFileDb is split into two: supportsDirDbs and
      requiresDirDbs. Then rather than HcPkg.init callers having to do the
      writeFile [] thing, HcPkg.init does it itself automatically based on the
      HcPkgInfo. In the case that supportsDirDbs is True but requiresDirDbs is
      False then we have a choice, to use dir style or file style. For
      compatability reasons, when using ghc/ghc-pkg for the inplace package db
      we want to use the old file style, even though dir style is supported.
      However in other circumstances (e.g. in places in cabal-install) we
      would like to use the dir style if it's supported, and there are no
      backwards compat issues. So HcPkg.init gains a new Bool arg to request
      using the file style if it's still supported. Only this mode is used
      within Cabal itself, but the non-compat mode is available for other
      users.
      
      The compiler-independent initPackageDB is left with the same old
      behaviour, but a new createPackageDB has the extra compat argument
      (which is only passed to hc-pkg for ghc-pkg).
      12b222af
  9. 09 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Implement ComponentId, replacing PackageKey and InstalledPackageId. · b083151f
      Edward Z. Yang authored
      
      
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b083151f
  10. 17 Aug, 2015 1 commit
  11. 16 Aug, 2015 1 commit
  12. 27 Jan, 2015 1 commit
  13. 18 Dec, 2014 1 commit
  14. 12 Dec, 2014 3 commits
  15. 08 Nov, 2014 1 commit
  16. 12 May, 2014 1 commit
  17. 24 Jul, 2013 1 commit
  18. 19 Apr, 2013 1 commit
  19. 17 Aug, 2012 1 commit
  20. 11 May, 2012 1 commit
    • pcapriotti's avatar
      Adapt to change in GHC package db flags. · 9e030da8
      pcapriotti authored
      GHC and ghc-pkg package db flags changed from '*-package-conf' to
      '*-package-db' in 7.5.  This commit follows the change and introduces a
      version check whenever those flags are used.
      9e030da8
  21. 23 Oct, 2011 1 commit
  22. 19 Jun, 2011 1 commit
  23. 25 May, 2011 1 commit
  24. 10 Feb, 2011 2 commits
  25. 16 Aug, 2010 1 commit
  26. 21 May, 2010 1 commit
  27. 15 May, 2010 1 commit
  28. 11 Dec, 2009 1 commit
  29. 02 Dec, 2009 1 commit
  30. 29 Nov, 2009 1 commit