Skip to content
Snippets Groups Projects
  1. Jan 18, 2016
    • Edward Z. Yang's avatar
      Switch from -this-package-key to -this-unit-id. · 240ddd7c
      Edward Z. Yang authored
      
      A small cosmetic change, but we have to do a bit of work to
      actually support it:
      
          - Cabal submodule update, so that Cabal passes us
            -this-unit-id when we ask for it.  This includes
            a Cabal renaming to be consistent with Unit ID, which
            makes ghc-pkg a bit more scrutable.
      
          - Build system is updated to use -this-unit-id rather than
            -this-package-key, to avoid deprecation warnings.  Needs
            a version test so I resurrected the old test we had
            (sorry rwbarton!)
      
          - I've *undeprecated* -package-name, so that we are in the same
            state as GHC 7.10, since the "correct" flag will have only
            entered circulation in GHC 8.0.
      
          - I removed -package-key.  Since we didn't deprecate -package-id
            I think this should not cause any problems for users; they
            can just change their code to use -package-id.
      
          - The package database is indexed by UNIT IDs, not component IDs.
            I updated the naming here.
      
          - I dropped the signatures field from ExposedModule; nothing
            was using it, and instantiatedWith from the package database
            field.
      
          - ghc-pkg was updated to use unit ID nomenclature, I removed
            the -package-key flags but I decided not to add any new flags
            for now.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: 23Skidoo, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1780
      240ddd7c
  2. Dec 28, 2015
  3. Nov 14, 2015
  4. Aug 05, 2014
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      explosion.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D80
      66218d15
  5. May 14, 2014
  6. Apr 19, 2014
  7. Jan 03, 2014
  8. Oct 26, 2013
  9. Sep 16, 2013
  10. Sep 11, 2013
  11. Aug 19, 2013
  12. Jul 03, 2013
  13. May 19, 2013
    • Ian Lynagh's avatar
      More build fixes · 06bc377d
      Ian Lynagh authored
      06bc377d
    • Ian Lynagh's avatar
      Fix build · 52719ad0
      Ian Lynagh authored
      If we use "smallInteger 0#" in the definitions, then that turns into
      an Integer literal, but the compiler can't handle Integer literals
      while compiling the integer package (as it can't look up the
      mkInteger Id yet).
      52719ad0
  14. Nov 30, 2012
  15. Aug 29, 2012
  16. Aug 05, 2012
  17. Jul 24, 2012
  18. Jul 10, 2012
  19. Mar 06, 2012
  20. Oct 14, 2011
  21. Sep 17, 2011
  22. Sep 13, 2011
  23. Aug 07, 2011
  24. Aug 06, 2011
  25. Jul 30, 2011
  26. Jul 29, 2011
  27. Jul 23, 2011
  28. Jul 22, 2011
  29. Apr 22, 2011
  30. Apr 05, 2011
  31. Jan 11, 2011
  32. Oct 23, 2010
  33. Sep 20, 2009
  34. Jul 22, 2009
Loading