This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 06 Oct, 2016 1 commit
  2. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      
      Finally, this also adds a new functor-like convenience function
      
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      
      for modifying the version number components.
      bb2026c4
  3. 22 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Update default-language & avoid default-extensions (#3880) · f87738df
      Herbert Valerio Riedel authored
      This upgrades the `default-language: Haskell98` to `Haskell2010`
      and removes `default-extensions: RankNTypes, FlexibleContexts`
      in favor of adding `LANGUAGE` pragmas where needed.
      
      Moroever, this also drops `LANGUAGE` pragmas which have become redundant
      due to `Haskell2010` (specifically, `EmptyDataDecls`,
      `ForeignFunctionInterface` and `PatternGuards`)
      
      Finally, an `other-extensions` specification is put in place for the
      `Cabal` library component.
      
      This helps loading up files directly in GHCi, such as e.g. `ghci Setup.hs`
      without having to specify `-X...` flags.
      f87738df
  4. 11 Sep, 2016 1 commit
    • ttuegel's avatar
      Revert "Respect GHC_PACKAGE_PATH" · 9c14b642
      ttuegel authored
      This reverts commit e7d2a62c due to a
      bug.
      
      The package databases obtained from GHC_PACKAGE_PATH should be stored in
      the LocalBuildInfo and passed to GHC when necessary; otherwise, the user
      could change GHC_PACKAGE_PATH causing GHC and Cabal to see inconsistent
      installed package sets. cabal-install should trigger reconfiguration if
      GHC_PACKAGE_PATH changes.
      9c14b642
  5. 06 Sep, 2016 4 commits
  6. 01 Sep, 2016 1 commit
  7. 26 Jul, 2016 2 commits
  8. 25 Jul, 2016 1 commit
  9. 24 Jul, 2016 1 commit
    • Edward Z. Yang's avatar
      As much as possible, expunge uses of localPkgDescr. · e3c64e6d
      Edward Z. Yang authored
      
      
      The big change here is that most of the functions in
      Distribution.Types.HookedBuildInfo have to take a
      PackageDescription explicitly.  I hate the new type,
      so I primed these new functions, and added functions
      which use 'localPkgDescr'.  Presently those have WARNINGs
      attached to them so people don't accidentally use them;
      once we fix 'HookedBuildInfo' we can change this.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e3c64e6d
  10. 14 Apr, 2016 1 commit
  11. 29 Mar, 2016 2 commits
    • Edward Z. Yang's avatar
      40d6f0af
    • Edward Z. Yang's avatar
      Implement "convenience libraries", fixes #269. · 2040c1c9
      Edward Z. Yang authored
      
      
      Convenience libraries are package-private libraries
      that can be used as part of executables, libraries, etc
      without being exposed to the external world.  Private
      libraries are signified using the
      
          library foo
      
      stanza.  Within a Cabal package, the name convenience library
      shadows the conventional meaning of package name in
      build-depends, so that references to "foo" do not indicate
      foo in Hackage, but the convenience library defined in the
      same package. (So, don't shadow Hackage packages!)
      
      This commit implements convenience libraries such that they
      ARE installed the package database (this prevents us from
      having to special case dynamically linked executables);
      in GHC 7.10 and later they are installed under the same
      package name as the package that contained them, but have
      a distinct "component ID" (one pay off of making the distinction
      between component IDs and installed package IDs.)
      
      There is a "default" library which is identified by the fact
      that its library name coincides with the package name.  There
      are some new convenience functions to permit referencing this.
      
      There are a few latent bugs in this commit which are fixed
      in later commits in this patchset.  (Those bugfixes required
      a bit of refactoring, so it's clearer if they're not
      with this patch.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2040c1c9
  12. 20 Feb, 2016 1 commit
  13. 18 Feb, 2016 1 commit
  14. 13 Feb, 2016 1 commit
  15. 30 Jan, 2016 1 commit
  16. 25 Jan, 2016 1 commit
  17. 16 Jan, 2016 3 commits
    • 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
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Remove instantiated-with and related support work. · 15e0e717
      Edward Z. Yang authored
      
      
      Backpack is going to have to rewrite this functionality.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      15e0e717
  18. 10 Jan, 2016 1 commit
  19. 16 Dec, 2015 6 commits
    • Duncan Coutts's avatar
      Extend ConfiguredProgram with search locations looked at · b39b906d
      Duncan Coutts authored
      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.
      b39b906d
    • Duncan Coutts's avatar
      Add mutli-instance support to registerPackage · 2d0a8781
      Duncan Coutts authored
      With support for GHC and GHCJS. All Cabal lib internal uses remain
      traditional single instance, so there's no change of behaviour.
      2d0a8781
    • 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
      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
    • Duncan Coutts's avatar
      Don't pass LocalBuildInfo to per-compiler registerPackage functions · b0b57da9
      Duncan Coutts authored
      Rather, pass the individual bits we need, which is the program db
      and in some cases the compiler. This is a step towards having the main
      registerPackage not take the LocalBuildInfo. That is useful in contexts
      like cabal-install where we do not have a full LocalBuildInfo, but we
      still want to be able to register packages in a compiler-agnostic way.
      b0b57da9
    • Duncan Coutts's avatar
      Change the interface to the per-compiler registerPackage functions · f1ca9680
      Duncan Coutts authored
      Remove the now-unused PackageDescription and inplace :: Bool args.
      
      Not yet changed the compiler-independent registerPackage.
      f1ca9680
  20. 01 Nov, 2015 1 commit
  21. 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
  22. 20 Aug, 2015 1 commit
    • thomie's avatar
      Strip libraries at install/copy time. Never strip libraries in build directory. · 7ef72b31
      thomie authored
      Two changes:
      
        * strip static libraries (.a files) at install/copy time, instead of
          at build time. Note that Cabal strips shared libraries (.so files)
          and executables at install/copy time also.
      
          This is needed for GHC, because it uses Cabal (via ghc-cabal copy)
          to install the boot libraries, and relies on Cabal to take of
          library stripping. Currently .so files indeed get properly stripped,
          but .a files do not.
      
          (Stripping static libraries at build time was introduced in
          60409cb9, with the explanation:
          "Call 'stripLib' from createLibArchive so that it's done only
          once.")
      
          This bug (if you want to call it that) partially explains the
          difference in size of a GHC installation before and after manual
          stripping, reported in
          https://github.com/haskell/cabal/issues/1622#issuecomment-62076817
          (The other parts are that the GHC build system currently doesn't
          strip executables on installation:
          https://ghc.haskell.org/trac/ghc/ticket/9087, and neither are the
          RTS library stripped, since they don't go through Cabal).
      
        * never strip the copy of a library in the build directory. Only
          strip the copy that is installed. Note that Cabal never strips
          executables in the build directory either.
      
          This might speed up compilation of a package under development,
          since stripping won't be performed for every 'cabal build'. It is
          also consistent with the GNU coding standards for 'install-strip':
      
            "install-strip should not strip the executables in the build
            directory which are being copied for installation. It should only
            strip the copies that are installed."
      
          Source:
          http://www.gnu.org/prep/standards/html_node/Standard-Targets.html
      7ef72b31
  23. 17 Aug, 2015 1 commit
  24. 16 Aug, 2015 1 commit
  25. 21 Jul, 2015 1 commit
    • Edward Z. Yang's avatar
      Refactor Cabal around the idea of "library names". · f47732a5
      Edward Z. Yang authored
      
      
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      f47732a5
  26. 26 Mar, 2015 1 commit
  27. 06 Mar, 2015 1 commit
  28. 23 Feb, 2015 1 commit