1. 21 May, 2018 1 commit
  2. 14 May, 2018 1 commit
    • Ben Gamari's avatar
      ghc-pkg: Configure handle encodings · cf88c2b1
      Ben Gamari authored
      This fixes #15021 using a the same approach as was used to fix the issue
      in ghc (#10762).
      
      Test Plan: Validate on Windows as user whose username contains
      non-ASCII characters
      
      Reviewers: simonmar
      
      Reviewed By: simonmar
      
      Subscribers: lehins, thomie, carter
      
      GHC Trac Issues: #15021
      
      Differential Revision: https://phabricator.haskell.org/D4642
      cf88c2b1
  3. 20 Nov, 2017 1 commit
  4. 19 Nov, 2017 1 commit
  5. 18 Nov, 2017 1 commit
    • Moritz Angermann's avatar
      Relocatable GHC · bb11a2d9
      Moritz Angermann authored
      GHC and the binary distribution that's produced is
      not relocatable outside of Windows.  This diff tries to
      address this for at least Linux and macOS.
      
      Reviewers: austin, hvr, bgamari, erikd, goldfire, Phyx
      
      Reviewed By: bgamari
      
      Subscribers: duog, rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D4121
      bb11a2d9
  6. 09 Nov, 2017 1 commit
    • Tamar Christina's avatar
      Update Win32 version for GHC 8.4. · bdd2d286
      Tamar Christina authored
      Update to Win32 2.6 which is the expected version release for 8.4
      
      This involves moving Cabal forward which brings some backwards incompatible
      changes that needs various fixups.
      
      Bump a bunch of submodules
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: angerman, thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D4133
      bdd2d286
  7. 17 May, 2017 1 commit
    • Edward Z. Yang's avatar
      Fix #13703 by correctly using munged names in ghc-pkg. · d9e9a9b3
      Edward Z. Yang authored
      Summary:
      Cabal internal libraries are implemented using a trick, where the 'name'
      field in ghc-pkg registration file is munged into a new form to keep
      each internal library looking like a distinct package to ghc-pkg and
      other tools; e.g. the internal library q from package p is named
      z-p-z-q.
      
      Later, Cabal library got refactored so that we made a closer distinction
      between these "munged" package names and the true package name of a
      package.  Unfortunately, this is an example of a refactor for clarity in
      the source code which ends up causing problems downstream, because the
      point of "munging" the package name was to make it so that ghc-pkg and
      similar tools transparently used MungedPackageName whereever they
      previously used PackageName (in preparation for them learning proper
      syntax for package name + component name).  Failing to do this meant
      that internal libraries from the same package (but with different
      names) clobber each other.
      
      This commit search-replaces most occurrences of PackageName in
      ghc-pkg and turns them into MungedPackageName. Otherwise there
      shouldn't be any functional differenes.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13703
      
      Differential Revision: https://phabricator.haskell.org/D3590
      d9e9a9b3
  8. 29 Apr, 2017 1 commit
  9. 26 Apr, 2017 1 commit
  10. 07 Mar, 2017 1 commit
  11. 03 Mar, 2017 1 commit
  12. 02 Mar, 2017 1 commit
  13. 28 Feb, 2017 1 commit
  14. 26 Feb, 2017 1 commit
  15. 23 Feb, 2017 1 commit
    • Tamar Christina's avatar
      Correct Windows libdir assumptions. · 8d64395b
      Tamar Christina authored
      GHC and ghc-pkg make some pretty hard assumptions about where they're
      running on Windows. They assume that they are always running from
      `foo/bin/ghc.exe` and that to find the `lib` folder they can drop
      `bin/ghc.exe` from the base path and append `lib`.
      
      This is already false for the testsuite, which when testing thenbindist
       has one test which puts the binaries in `inplace/test   spaces`.
      
      For some reason before this was either being skipped or mysteriously 
      passing.
      But as of `2017.02.11` our luck ran out.
      
      the testsuite triggers a failure such as those in #13310
      
      Let's soften the assumption and just check that `../lib` exists instead.
      
      80 chars
      
      Test Plan: ./validate
      
      Reviewers: austin, erikd, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D3158
      8d64395b
  16. 09 Feb, 2017 1 commit
  17. 04 Feb, 2017 1 commit
    • Takenobu Tani's avatar
      Fix comment (old file names) in mk/ and utils/ · bd818a7c
      Takenobu Tani authored
      There ware some old file names (.lhs, ...) at comments.
      
      * mk/config.mk.in
        - compiler/hsSyn/HsExpr.lhs -> HsExpr.hs
      
      * utils/ghc-pkg/Main.hs
        - compiler/main/Packages.lhs -> Packages.hs
      
      * utils/genapply/Main.hs
        - CgRetConv.lhs -> * REMOVE THIS COMMENT (OLDER FILE THAN GHC6) *
        - Constants.lhs -> Constants.hs
        - compiler/codeGen/CgCallConv.lhs -> compiler/codeGen/StgCmmLayout.hs
        - Apply.hc -> Apply.cmm
        - HeapStackCheck.hc -> HeapStackCheck.cmm
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3077
      bd818a7c
  18. 21 Dec, 2016 1 commit
    • Edward Z. Yang's avatar
      Support for abi-depends for computing shadowing. · ee4e1654
      Edward Z. Yang authored
      Summary:
      This is a complete fix based off of
      ed7af26606b3a605a4511065ca1a43b1c0f3b51d for handling
      shadowing and out-of-order -package-db flags simultaneously.
      
      The general strategy is we first put all databases together,
      overriding packages as necessary.  Once this is done, we successfully
      prune out broken packages, including packages which depend on a package
      whose ABI differs from the ABI we need.
      
      Our check gracefully degrades in the absence of abi-depends, as
      we only check deps which are recorded in abi-depends.
      
      Contains time and Cabal submodule update.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: niteria, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2846
      
      GHC Trac Issues: #12485
      ee4e1654
  19. 12 Nov, 2016 1 commit
  20. 22 Oct, 2016 1 commit
    • Duncan Coutts's avatar
      Add and use a new dynamic-library-dirs field in the ghc-pkg info · f41a8a36
      Duncan Coutts authored
      Summary:
      Build systems / package managers want to be able to control the file
      layout of installed libraries. In general they may want/need to be able
      to put the static libraries and dynamic libraries in different places.
      The ghc-pkg library regisrtation needs to be able to handle this.
      
      This is already possible in principle by listing both a static lib dir
      and a dynamic lib dir in the library-dirs field (indeed some previous
      versions of Cabal did this for shared libs on ELF platforms).
      
      The downside of listing both dirs is twofold. There is a lack of
      precision, if we're not careful with naming then we could end up
      picking up the wrong library. The more immediate problem however is
      that if we list both directories then both directories get included
      into the ELF and Mach-O shared object runtime search paths. On ELF this
      merely slows down loading of shared libs (affecting prog startup time).
      On the latest OSX versions this provokes a much more serious problem:
      that there is a rather low limit on the total size of the section
      containing the runtime search path (and lib names and related) and thus
      listing any unnecessary directories wastes the limited space.
      
      So the solution in this patch is fairly straightforward: split the
      static and dynamic library search paths in the ghc-pkg db and its use
      within ghc. This is a traditional solution: pkg-config has the same
      static / dynamic split (though it describes in in terms of private and
      public, but it translates into different behaviour for static and
      dynamic linking).
      
      Indeed it would make perfect sense to also have a static/dynamic split
      for the list of the libraries to use i.e. to have dynamic variants of
      the hs-libraries and extra-libraries fields. These are not immediately
      required so this patch does not add it, but it is a reasonable
      direction to follow.
      
      To handle compatibility, if the new dynamic-library-dirs field is not
      specified then its value is taken from the library-dirs field.
      
      Contains Cabal submodule update.
      
      Test Plan:
      Run ./validate
      
      Get christiaanb and carter to test it on OSX Sierra, in combination
      with Cabal/cabal-install changes to the default file layout for
      libraries.
      
      Reviewers: carter, austin, hvr, christiaanb, bgamari
      
      Reviewed By: christiaanb, bgamari
      
      Subscribers: ezyang, Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2611
      
      GHC Trac Issues: #12479
      f41a8a36
  21. 08 Oct, 2016 3 commits
  22. 02 Oct, 2016 2 commits
  23. 08 Aug, 2016 1 commit
  24. 30 Jun, 2016 2 commits
  25. 10 Feb, 2016 1 commit
    • Edward Z. Yang's avatar
      Error early when you register with too old a version of Cabal. · d80caca1
      Edward Z. Yang authored
      On the GHC 8.0 RCs, multiple users reported a very strange error
      whereby GHC would complain that the symbols names recorded in interface
      files did not match the expected name.  The reason for this is
      that they were using an old version of Cabal which chose symbol
      names differently from the installed package ID ('id' field) which
      the package was to be installed with; GHC 8.0 now mandates that
      these coincides.
      
      This change adds a test to ghc-pkg to make sure that 'id' and 'key'
      (which is how Cabal previously reported what the symbol name
      was supposed to be) match; if they don't match or key is missing,
      we assume that the Cabal was too old.
      
      Bikeshed points:
      
          - Should we offer more information about how to upgrade
            Cabal correctly (i.e. specify a version?)
      
          - Should we allow for a missing 'key'?  If we allow for
            'key' to be missing, we lose the ability to detect
            Cabal from GHC 7.8 or earlier being used.  If we
            require it to be specified, then it will not be possible
            for Cabal to deprecate the (unused) field and remove it
            without having BC for 8.0.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, hvr
      
      Reviewed By: hvr
      
      Subscribers: bergmark, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1892
      
      GHC Trac Issues: #11558
      d80caca1
  26. 01 Feb, 2016 1 commit
    • Edward Z. Yang's avatar
      Simplify ghc-boot database representation with new type class. · 0d601657
      Edward Z. Yang authored
      Previously, we had an 'OriginalModule' type in ghc-boot which
      was basically identical to 'Module', and we had to do a bit of
      gyrating to get it converted into the right form.  This commit
      introduces a new typeclass, 'DbModuleRep' which represents types
      which we know how to serialize to and from the (now renamed) 'DbModule'
      type.
      
      The upshot is that we can just store 'Module's DIRECTLY in
      the 'InstalledPackageInfo', no conversion needed.
      
      I took the opportunity to clean up ghc-pkg to make its use of
      the 'BinaryStringRep' classes more type safe.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1811
      0d601657
  27. 18 Jan, 2016 1 commit
    • 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
  28. 31 Dec, 2015 2 commits
  29. 11 Dec, 2015 1 commit
  30. 07 Dec, 2015 2 commits
  31. 29 Nov, 2015 1 commit
  32. 18 Oct, 2015 1 commit
  33. 15 Oct, 2015 2 commits
    • Edward Z. Yang's avatar
      Rename package key to unit ID, and installed package ID to component ID. · b92a51f5
      Edward Z. Yang authored
      Comes with Haddock submodule update.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b92a51f5
    • Edward Z. Yang's avatar
      Update Cabal to HEAD, IPID renamed to Component ID. · 5b0191f7
      Edward Z. Yang authored
      This commit contains a Cabal submodule update which unifies installed
      package IDs and package keys under a single notion, a Component ID.
      We update GHC to keep follow this unification.  However, this commit
      does NOT rename installed package ID to component ID and package key to
      unit ID; the plan is to do that in a companion commit.
      
          - Compiler info now has "Requires unified installed package IDs"
      
          - 'exposed' is now expected to contain unit keys, not IPIDs.
      
          - Shadowing is no more.  We now just have a very simple strategy
            to deal with duplicate unit keys in combined package databases:
            if their ABIs are the same, use the latest one; otherwise error.
            Package databases maintain the invariant that there can only
            be one entry of a unit ID.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr, goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1184
      
      GHC Trac Issues: #10714
      5b0191f7