1. 07 Sep, 2013 1 commit
  2. 24 Jun, 2013 1 commit
  3. 30 May, 2013 1 commit
  4. 28 Apr, 2013 3 commits
  5. 15 Feb, 2013 1 commit
  6. 30 Nov, 2012 1 commit
  7. 08 Nov, 2012 1 commit
  8. 25 Oct, 2012 2 commits
  9. 11 Oct, 2012 1 commit
  10. 18 Jul, 2012 1 commit
  11. 02 Jul, 2012 1 commit
  12. 27 May, 2012 1 commit
  13. 16 May, 2012 1 commit
  14. 15 May, 2012 1 commit
    • pcapriotti's avatar
      Rename package-conf flags to package-db. · ca2debb2
      pcapriotti authored
      Rename package database flags in both GHC and ghc-pkg so that they are
      consistent with Cabal nomenclature.
      
      Add a version check to the build system so that the correct set of
      package db flags are used when the bootstrapping GHC has version < 7.5.
      ca2debb2
  15. 08 Mar, 2012 1 commit
  16. 19 Jun, 2011 1 commit
  17. 18 Jun, 2011 1 commit
  18. 10 Jun, 2011 1 commit
  19. 09 Jun, 2011 2 commits
  20. 25 May, 2011 6 commits
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Provide the pkgroot value in ghc-pkg dump & describe when necessary · f35a3d24
      Duncan Coutts authored
      Tools handling installed packages need to be able to interpret the
      paths which are relative to the ${pkgroot} which means they need to
      know the value of ${pkgroot}. With ghc-pkg this is not always obvious
      since ghc-pkg does not currently have any way machine interface for
      reporting the location of its package dbs (global, user). The solution
      we have arrived at is simply to emit the pkgroot as an extra field
      when it is needed.
      
      There are two cases:
       * --no-expand-pkgroot: ghc-pkg dump/describe will not expand the
         ${pkgroot} var, so it will appear literally in the output and the
         pkgroot field will be generated so that tools know what value to
         use for the ${pkgroot}.
       * --expand-pkgroot: ghc-pkg dump/describe will expand the ${pkgroot}
         and ${pkgrooturl} vars and will not generate the pkgroot field.
      
      The defaults are:
       * ghc-pkg dump/describe --no-expand-pkgroot
       * ghc-pkg field --expand-pkgroot
      f35a3d24
    • Duncan Coutts's avatar
      Add stricter ghc-pkg checks on package file/dir/url fields · f61d53d3
      Duncan Coutts authored
      The haddock-html and haddock-interface fields are now checked
      as well. Had to fix up ghc-cabal as it used relative paths for
      the inplace package's haddock-html. It turns out that these
      were never used so it could simply be omitted.
      f61d53d3
    • Duncan Coutts's avatar
      Implement ${pkgroot} spec, allows relocatable registered packages · 40b6bd47
      Duncan Coutts authored
      Historically ghc implemented relocatable packages by allowing
      "$topdir" in the package registration info and having ghc expand
      this with its notion of $topdir. The topdir refers to where ghc
      itself is installed (specifically the libdir).
      
      The ${pkgroot} spec takes this idea and makes it portable.
      (http://www.haskell.org/pipermail/libraries/2009-May/011772.html)
      Instead of paths relative to where ghc is installed, they can be
      relative to the package database itself. Thus it is no longer a
      ghc-specific idea and can work for package collections other than
      the global package db.
      40b6bd47
    • Duncan Coutts's avatar
      Deprecate the ghc-pkg --auto-ghci-libs flag · 78185538
      Duncan Coutts authored
      It was never a universal solution. It only worked with the GNU linker.
      It has not been used by Cabal for ages. GHCi can now load .a files so
      it will not be needed in future.
      78185538
    • Duncan Coutts's avatar
      ghc-pkg: don't expand ${name}-style env vars by default · 6ef41c26
      Duncan Coutts authored
      For shell-based build systems the feature is still available as:
        ghc-pkg register --expand-env-vars
      
      Historically, ghc-pkg allowed environment variables to appear in the
      input files for ghc-pkg register. They are not stored in the package
      database but are expanded upon registration. This feature helped for
      build systems based on makefiles and shell scripts. These days the
      vast majority of such files are generated by Cabal and we don't want
      any ${name} strings (e.g. perhaps in a package description) getting
      accidentally interpreted as an environment variable.
      6ef41c26
  21. 14 May, 2011 1 commit
  22. 18 Dec, 2010 2 commits
  23. 15 Dec, 2010 1 commit
  24. 27 Nov, 2010 1 commit
  25. 13 Oct, 2010 1 commit
  26. 12 Oct, 2010 1 commit
  27. 06 Oct, 2010 1 commit
  28. 01 Aug, 2010 1 commit
  29. 25 Jul, 2010 1 commit
  30. 15 Jul, 2010 1 commit