1. 22 Sep, 2019 1 commit
  2. 10 Aug, 2019 1 commit
    • Joachim Breitner's avatar
      Consolidate `TablesNextToCode` and `GhcUnreigsterised` in configure (#15548) · 81860281
      Joachim Breitner authored
      `TablesNextToCode` is now a substituted by configure, where it has the
      correct defaults and error handling. Nowhere else needs to duplicate
      that, though we may want the compiler to to guard against bogus settings
      files.
      
      I renamed it from `GhcEnableTablesNextToCode` to `TablesNextToCode` to:
      
       - Help me guard against any unfixed usages
      
       - Remove any lingering connotation that this flag needs to be combined
         with `GhcUnreigsterised`.
      
      Original reviewers:
      
      Original subscribers: TerrorJack, rwbarton, carter
      
      Original Differential Revision: https://phabricator.haskell.org/D5082
      81860281
  3. 25 Mar, 2019 1 commit
    • Takenobu Tani's avatar
      Update Wiki URLs to point to GitLab · 3769e3a8
      Takenobu Tani authored
      This moves all URL references to Trac Wiki to their corresponding
      GitLab counterparts.
      
      This substitution is classified as follows:
      
      1. Automated substitution using sed with Ben's mapping rule [1]
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
      
      2. Manual substitution for URLs containing `#` index
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
      
      3. Manual substitution for strings starting with `Commentary`
          Old: Commentary/XxxYyy...
          New: commentary/xxx-yyy...
      
      See also !539
      
      [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
      3769e3a8
  4. 20 Sep, 2018 1 commit
  5. 31 Jul, 2018 1 commit
  6. 27 Jul, 2018 1 commit
  7. 15 Jun, 2018 1 commit
  8. 14 May, 2018 2 commits
  9. 01 May, 2018 1 commit
  10. 31 Mar, 2018 1 commit
    • Tamar Christina's avatar
      Remove MAX_PATH restrictions from RTS, I/O manager and various utilities · 4de585a5
      Tamar Christina authored
      Summary:
      This shims out fopen and sopen so that they use modern APIs under the hood
      along with namespaced paths.
      
      This lifts the MAX_PATH restrictions from Haskell programs and makes the new
      limit ~32k.
      
      There are only some slight caveats that have been documented.
      
      Some utilities have not been upgraded such as lndir, since all these things are
      different cabal packages I have been forced to copy the source in different places
      which is less than ideal. But it's the only way to keep sdist working.
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #10822
      
      Differential Revision: https://phabricator.haskell.org/D4416
      4de585a5
  11. 03 Feb, 2018 1 commit
    • Ben Gamari's avatar
      ghc-prim: Emulate C11 atomics when not available · 217e4170
      Ben Gamari authored
      GCC's __sync primitives apparently "usually" imply a full barrier,
      meaning they can be used to emulate the more precise C11 atomics albeit
      with a loss of efficiency. This restores compatibility with GCC 4.4.
      
      This partially reverts commit 59de2909.
      
      Test Plan: Validate on Centos
      
      Reviewers: hvr, simonmar, trommler
      
      Subscribers: rwbarton, thomie, erikd, carter
      
      GHC Trac Issues: #14244
      
      Differential Revision: https://phabricator.haskell.org/D4364
      217e4170
  12. 15 Nov, 2017 1 commit
    • Peter Trommler's avatar
      RTS: Disable warnings in ffi.h · 8b1020ed
      Peter Trommler authored
      The update of GHC's in-tree libffi causes warnings about
      undefined macros and hence validate fails.
      
      Also mark broken tests that have a ticket.
      
      Fixes #14353
      
      Test Plan: ./validate (on AIX and powerpc if possible)
      
      Reviewers: bgamari, hvr, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, rwbarton, thomie
      
      GHC Trac Issues: #14353, #11259, #14455, #11261
      
      Differential Revision: https://phabricator.haskell.org/D4181
      8b1020ed
  13. 06 Nov, 2017 1 commit
    • Peter Trommler's avatar
      Update autoconf test for gcc to require 4.7 and up · 59de2909
      Peter Trommler authored
      Fixing #14244 required the newer gcc atomic built-ins that are provided
      from 4.7 and up. This updates the test to check for minimum gcc version
      4.7.
      
      The version tests for 3.4 (!), 4.4, and 4.6 are no longer needed and can
      be removed. This makes the build system simpler.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, hvr, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D4165
      59de2909
  14. 16 Oct, 2017 1 commit
  15. 05 Sep, 2017 1 commit
    • Tamar Christina's avatar
      Replace hashing function for string keys implementation with xxhash · 542f89ff
      Tamar Christina authored
      When doing profiling on startup time of ghci on Windows, both cold and
      startup loading static LLVM libs, the profiler is showing a glaring red
      spot on the division operation of the the hashStr function.
      
      In fact profiling shows 14% of the time is spent hashing the keys.
      
      So I am replacing the hash function with xxHash which is a very fast
      non-crypto hash. It's faster than MurMurHash which node etc use.
      
      It also passes SMHasher. I can provide if required the collected raw
      data.  But from analysis done on the keys, xxHash does not introduce
      more collisions than before, the amount splits seem about the same and
      the distributions among the buckets are slightly more uniform than
      before.
      
      However the runtime dropped enough to remove the function completely
      from the profiler's report.
      
      There's also a noticeable improvement in responsiveness.
      
      xxHash is BSD licensed and can be found
      https://github.com/Cyan4973/xxHash
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13165
      
      Differential Revision: https://phabricator.haskell.org/D3909
      542f89ff
  16. 29 Aug, 2017 1 commit
    • Tamar Christina's avatar
      Add gen-dll as replacement for dll-split · 5f6a8204
      Tamar Christina authored
      Summary:
      This tool can be used to generate dll's for any list of object files
      given to it. It will then repartition them automatically to fit within
      a dll and generates as many dll's as needed to do this. Cyclic dependencies
      between these generated dlls are handle automatically so there is no need
      to tell it how to partition.
      
      It is also a lot more general than `dll-split` as it is able to split any
      package not just `libGHC`. It also uses a trick using GNU style import libraries
      to hide the splitting from the rest of the pipeline. Which means come linking time
      you don't need to know which dll contains what symbol or how many split dlls were
      created.
      
      The import libraries are by default created with libtool. However since libtool is BFD
      based it is very slow. So if present and detected by configure the `genlib` tool
      from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.
      
      To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.
      
      More detailed explaination of the process can be found here
      https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force
      
      GHC Trac Issues: #5987
      
      Differential Revision: https://phabricator.haskell.org/D3883
      5f6a8204
  17. 17 Aug, 2017 1 commit
  18. 11 May, 2017 1 commit
    • Ben Gamari's avatar
      rts: Don't build StgCRunAsm.S if unregisterised · aa8dcb33
      Ben Gamari authored
      StgCRunAsm.S provides StgCRun on powerpc64le platforms when
      registerised.  However, in the unregisterised setting we use the
      mini-interpreter and consequently shouldn't build StgCRunAsm.S lest we
      get duplicate symbols.
      
      Test Plan: Build unregisterised compiler on AIX.
      
      Reviewers: hvr, trommler, austin, simonmar
      
      Reviewed By: trommler, simonmar
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3560
      aa8dcb33
  19. 29 Apr, 2017 1 commit
  20. 23 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      rts: tweak cross-compilation to mingw32 · 745032dd
      Sergei Trofimovich authored
      Found the problem on x86_64-linux host where
      I tried to cross-compile GHC to windows as:
      
          $ ./configure --target=i686-w64-mingw32 \
                        Windres=i686-w64-mingw32-windres \
                        DllWrap=i686-w64-mingw32-dllwrap
      
      As a result build failed as POSIX bits of RTS.
      For example 'rts/posix/OSMem.c' contains unix-specific
      mmap() syscalls and constants and thus can't be compiled
      by i686-w64-mingw32 toolchain.
      
      It's caused by the following part of 'rts/ghc.mk':
      
        ifeq "$(HostOS_CPP)" "mingw32"
        ALL_DIRS += win32
        else
        ALL_DIRS += posix
        endif
      
      In our case _CPP variables are defined this way (project.mk):
        BuildOS_CPP                = linux
        HostOS_CPP                 = linux
        TargetOS_CPP               = mingw32
      
      RTS should never be built for 'BuildOS' or 'HostOS' as it's
      always built by ghc-stage1 (targeted at TargetOS).
      
      The change is to flip 'HostOS_CPP' to 'TargetOS_CPP' in 'rts/ghc.mk'.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      745032dd
  21. 05 Apr, 2017 1 commit
  22. 04 Apr, 2017 1 commit
  23. 28 Feb, 2017 1 commit
    • Moritz Angermann's avatar
      Drop copy step from the rts/ghc.mk · 3e33d334
      Moritz Angermann authored
      Recently I've used a different build system for building the
      rts (Xcode).  And in doing so, I looked through the rts/ghc.mk
      to figure out how to build the rts.
      
      In general it's quite straight forward to just compile all the
      c files with the proper flags.
      
      However there is one rather awkward copy step that copies some
      files for special handling for the rts way.
      
      I'm wondering if the proposed solution in this diff is better
      or worse than the current situation?
      
      The idea is to keep the files, but use #includes to produce
      identical files with just an additional define. It does however
      produce empty objects for non threaded ways.
      
      Reviewers: ezyang, bgamari, austin, erikd, simonmar, rwbarton
      
      Reviewed By: bgamari, simonmar, rwbarton
      
      Subscribers: rwbarton, thomie, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3237
      3e33d334
  24. 12 Feb, 2017 1 commit
    • olsner's avatar
      Apply SplitSections to all C compilations · a50082c1
      olsner authored
      Previously this was added only to the RTS's C files (those are the bulk
      of it though), but there are C bits in ghc-prim, integer-gmp and base
      too.
      
      Followup for #8405, allows the large table of character properties in
      base to be stripped when not used.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: thomie, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3121
      a50082c1
  25. 21 Oct, 2016 1 commit
  26. 31 May, 2016 1 commit
  27. 24 May, 2016 1 commit
    • Erik de Castro Lopo's avatar
      Runtime linker: Break m32 allocator out into its own file · fe8a4e5d
      Erik de Castro Lopo authored
      This makes the code a little more modular and allows the removal of some
      CPP hackery. By providing dummy implementations of of the `m32_*`
      functions (which simply call `errorBelch`) it means that the call sites
      for these functions are syntax checked even when `RTS_LINKER_USE_MMAP`
      is `0`.
      
      Also changes some size parameter types from `unsigned int` to `size_t`.
      
      Test Plan: Validate on Linux, OS X and Windows
      
      Reviewers: Phyx, hsyl20, bgamari, simonmar, austin
      
      Reviewed By: simonmar, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2237
      fe8a4e5d
  28. 16 Apr, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Rework CC/CC_STAGE0 handling in `configure.ac` · 865602e0
      Herbert Valerio Riedel authored
      Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
      scheme use the `CC=...` style scheme.
      
      The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
      stage{1,2,3}, while having a separate _STAGE0 set of env-vars
      denote the bootstrap-toolchain flags/programs.
      
      This should be simpler, less confusing, and somewhat more in line with
      Autoconf's idioms (allowing us to reuse more of Autoconf rather than
      (re)inventing our own confusing non-standard m4 macros to do stuff that
      Autoconf could almost do already for us)
      
      Morever, expose CC_STAGE0 as a so-called "precious" variable.
      
      So now we can better control which bootstrapping gcc is used
      (by default the one used by the stage0 ghc, unless CC_STAGE0 is
      overriden)
      
      ```
      Some influential environment variables:
        CC_STAGE0   C compiler command (bootstrap)
        CC          C compiler command
        CFLAGS      C compiler flags
        ...
      
      Use these variables to override the choices made by `configure' or to
      help it to find libraries and programs with nonstandard names/locations.
      ```
      
      Test Plan: I've tested that cross-compiling with
      `--target=powerpc-linux-gnu` still works, and tried a few variants of
      settting `CC=` and `CC_STAGE0=`; `./validate` passed as well
      
      Reviewers: erikd, austin, bgamari, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2078
      865602e0
  29. 24 Mar, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Add NCG support for AIX/ppc32 · df26b955
      Herbert Valerio Riedel authored
      This extends the previous work to revive the unregisterised GHC build
      for AIX/ppc32. Strictly speaking, AIX runs on POWER4 (and later)
      hardware, but the PPC32 instructions implemented in the PPC NCG
      represent a compatible subset of the POWER4 ISA.
      
      IBM AIX follows the PowerOpen ABI (and shares many similiarites with the
      Linux PPC64 ELF V1 NCG backend) but uses the rather limited XCOFF
      format (compared to ELF).
      
      This doesn't support dynamic libraries yet.
      
      A major limiting factor is that the AIX assembler does not support the
      `@ha`/`@l` relocation types nor the ha16()/lo16() functions Darwin's
      assembler supports. Therefore we need to avoid emitting those. In case
      of numeric literals we simply compute the functions ourselves, while for
      labels we have to use local TOCs and hope everything fits into a 16bit
      offset (for ppc32 this gives us at most 16384 entries per TOC section,
      which is enough to compile GHC).
      
      Another issue is that XCOFF doesn't seem to have a relocation type for
      label-differences, and therefore the label-differences placed into
      tables-next-to-code can't be relocated, but the linker may rearrange
      different sections, so we need to place all read-only sections into the
      same `.text[PR]` section to workaround this.
      
      Finally, the PowerOpen ABI distinguishes between function-descriptors
      and actualy entry-point addresses. For AIX we need to be specific when
      emitting assembler code whether we want the address of the function
      descriptor `printf`) or for the entry-point (`.printf`). So we let the
      asm pretty-printer prefix a dot to all emitted subroutine
      calls (i.e. `BL`) on AIX only. For now, STG routines' entry-point labels
      are not prefixed by a label and don't have any associated
      function-descriptor.
      
      Reviewers: austin, trommler, erikd, bgamari
      
      Reviewed By: trommler, erikd, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D2019
      df26b955
  30. 27 Jan, 2016 1 commit
  31. 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
  32. 18 Nov, 2015 1 commit
  33. 12 Nov, 2015 1 commit
    • olsner's avatar
      Implement function-sections for Haskell code, #8405 · 4a32bf92
      olsner authored
      This adds a flag -split-sections that does similar things to
      -split-objs, but using sections in single object files instead of
      relying on the Satanic Splitter and other abominations. This is very
      similar to the GCC flags -ffunction-sections and -fdata-sections.
      
      The --gc-sections linker flag, which allows unused sections to actually
      be removed, is added to all link commands (if the linker supports it) so
      that space savings from having base compiled with sections can be
      realized.
      
      Supported both in LLVM and the native code-gen, in theory for all
      architectures, but really tested on x86 only.
      
      In the GHC build, a new SplitSections variable enables -split-sections
      for relevant parts of the build.
      
      Test Plan: validate with both settings of SplitSections
      
      Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari
      
      Reviewed By: simonmar, thomie, bgamari
      
      Subscribers: hsyl20, erikd, kgardas, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1242
      
      GHC Trac Issues: #8405
      4a32bf92
  34. 07 Nov, 2015 1 commit
    • Tamar Christina's avatar
      Allow the GHCi Linker to resolve related dependencies when loading DLLs · 6e6438e1
      Tamar Christina authored
      Summary:
      GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's
      that are not on the standard Windows load path:
      
      1. The directory from which the application loaded.
      2. The current directory.
      3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
      4. The 16-bit system directory. There is no function that obtains the path of this directory,
         but it is searched.
      5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
      6. The directories that are listed in the PATH environment variable.
         Note that this does not include the per-application path specified by the
         AppPaths registry key. The App Paths key is not used when computing the DLL search path.
      
      So what this means is given two DLLs `A` and `B` and `B` depending on `A`.
      If we put both DLLs into a new folder bin and then call GHC with:
      
      `ghc -L$(PWD)/bin -lB`
      
      the loading will fail as the Windows loader will try to load the dependency of `B` and fail
      since it cannot find `A`.
      
      *IMPORTANT* this patch drops XP Support.
      The  APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista
      via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has
      not been installed on certain machines. For those machines I display a warning and
      temporarily expand the `PATH` to allow it to load.
      
      This patch will make sure that paths provided by the user with `-L` *and* the folder in which a
      DLL is found are added to the search path. It does so using one of two methods depending upon how
      new of a Windows version we are running on:
      
      - If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`.
         The order of which these directories are searched is nondeterministic.
      - If the APIs are not available it means that we're running on a pretty old unpatched machine.
        But if it's being used in an environment with no internet access it may be the case.
        So if the APIs are not available we temporarily extend the `PATH` with the directories.
        A warning is also displayed to the user informing them that the linking may fail,
        and if it does, install the needed patch. The `PATH` variable has limitations.
      
      Test Plan:
      ./validate
      
      Added two new test T10955 and T10955dyn
      
      Reviewers: erikd, bgamari, thomie, hvr, austin
      
      Reviewed By: erikd, thomie
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1340
      
      GHC Trac Issues: #10955
      6e6438e1
  35. 17 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Libdw: Add libdw-based stack unwinding · a6a3dabc
      Ben Gamari authored
      This adds basic support to the RTS for DWARF-assisted unwinding of the
      Haskell and C stack via libdw. This only adds the infrastructure;
      consumers of this functionality will be introduced in future diffs.
      
      Currently we are carrying the initial register collection code in
      Libdw.c but this will eventually make its way upstream to libdw.
      
      Test Plan: See future patches
      
      Reviewers: Tarrasch, scpmw, austin, simonmar
      
      Reviewed By: austin, simonmar
      
      Subscribers: simonmar, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1196
      
      GHC Trac Issues: #10656
      a6a3dabc
  36. 21 Aug, 2015 1 commit
    • thomie's avatar
      Build system: simplify install.mk.in · 47493e60
      thomie authored
      This will allow fixing #1851 more easily
      ("make install-strip" should work).
      
      This reverts 57e2a81c:
        "On Cygwin, use a Cygwin-style path for /bin/install's destination"
      
      Update submodule haddock and hsc2hs.
      47493e60
  37. 03 Jul, 2015 1 commit
    • Peter Trommler's avatar
      Implement PowerPC 64-bit native code backend for Linux · d3c1dda6
      Peter Trommler authored
      Extend the PowerPC 32-bit native code generator for "64-bit
      PowerPC ELF Application Binary Interface Supplement 1.9" by
      Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
      OpenPOWER ABI for Linux Supplement" by IBM.
      The latter ABI is mainly used on POWER7/7+ and POWER8
      Linux systems running in little-endian mode. The code generator
      supports both static and dynamic linking. PowerPC 64-bit
      code for ELF ABI 1.9 and 2 is mostly position independent
      anyway, and thus so is all the code emitted by the code
      generator. In other words, -fPIC does not make a difference.
      
      rts/stg/SMP.h support is implemented.
      
      Following the spirit of the introductory comment in
      PPC/CodeGen.hs, the rest of the code is a straightforward
      extension of the 32-bit implementation.
      
      Limitations:
      * Code is generated only in the medium code model, which
        is also gcc's default
      * Local symbols are not accessed directly, which seems to
        also be the case for 32-bit
      * LLVM does not work, but this does not work on 32-bit either
      * Must use the system runtime linker in GHCi, because the
        GHC linker for "static" object files (rts/Linker.c) for
        PPC 64-bit is not implemented. The system runtime
        (dynamic) linker works.
      * The handling of the system stack (register 1) is not ELF-
        compliant so stack traces break. Instead of allocating a new
        stack frame, spill code should use the "official" spill area
        in the current stack frame and deallocation code should restore
        the back chain
      * DWARF support is missing
      
      Fixes #9863
      
      Test Plan: validate (on powerpc, too)
      
      Reviewers: simonmar, trofi, erikd, austin
      
      Reviewed By: trofi
      
      Subscribers: bgamari, arnons1, kgardas, thomie
      
      Differential Revision: https://phabricator.haskell.org/D629
      
      GHC Trac Issues: #9863
      d3c1dda6
  38. 22 Jun, 2015 1 commit
    • Edward Z. Yang's avatar
      Rename $1_$2_$3_LIB_NAME to LIB_FILE. · 01f7e440
      Edward Z. Yang authored
      Summary:
      When we introduced user-friendly library names
      (e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of
      unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to
      be written out by ghc-cabal, $1_$2_LIB_NAME.
      
      What I didn't realize at the time was that this conflicts
      with an existing variable in the build system, $1_$2_$3_LIB_NAME,
      which (confusingly) refers to something like
      'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'.  This is pretty
      confusing (despite never conflicting), so I renamed this variable
      to LIB_FILE for enhanced greppability.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1002
      01f7e440
  39. 10 Apr, 2015 1 commit