1. 09 Feb, 2016 2 commits
    • Ben Gamari's avatar
      Unset GREP_OPTIONS in build system · bfec4a6a
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Test Plan: GREP_OPTIONS=--blah ./validate
      Reviewers: austin, thomie
      Reviewed By: thomie
      Differential Revision: https://phabricator.haskell.org/D1887
      GHC Trac Issues: #11530
    • Thomas Miedema's avatar
      Early error when crosscompiling + haddock/docs · 04fb7813
      Thomas Miedema authored and Ben Gamari's avatar Ben Gamari committed
      When CrossCompiling=YES or Stage1Only=YES, building the haddocks and the
      User's Guide should be skipped, because haddock and mkUserGuidePart
      depend on the GHC API.
      See Note [No stage2 packages when CrossCompiling or Stage1Only] for
      There are several places in the build system where the variables
      HADDOCK_DOCS and BUILD_SPHINX_* are checked. Instead of also checking
      for the variables CrossCompiling or Stage1Only in all those places,
      `make` will now exit with a nice error message when the user requests
      the impossible.
      Reviewers: rwbarton, austin, bgamari
      Reviewed By: bgamari
      Differential Revision: https://phabricator.haskell.org/D1882
  2. 27 Jan, 2016 1 commit
    • Tamar Christina's avatar
      Enable RemoteGHCi on Windows · 44a5d51a
      Tamar Christina authored and Ben Gamari's avatar Ben Gamari committed
      Makes the needed changes to make RemoteGHCi work on Windows.
      The approach passes OS Handles areound instead of the Posix Fd
      as on Linux.
      The reason is that I could not find any real documentation about
      the behaviour of Windows w.r.t inheritance and Posix FDs.
      The implementation with Fd did not seem to be able to find the Fd
      in the child process. Instead I'm using the much better documented
      approach of passing inheriting handles.
      This requires a small modification to the `process` library.
      Test Plan: ./validate On Windows x86_64
      Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr
      Reviewed By: simonmar
      Subscribers: #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D1836
      GHC Trac Issues: #11100
  3. 18 Jan, 2016 1 commit
  4. 10 Jan, 2016 1 commit
  5. 08 Jan, 2016 1 commit
    • Simon Marlow's avatar
      Enable stack traces with ghci -fexternal-interpreter -prof · 6be09e88
      Simon Marlow authored
      The main goal here is enable stack traces in GHCi.  After this change,
      if you start GHCi like this:
        ghci -fexternal-interpreter -prof
      (which requires packages to be built for profiling, but not GHC
      itself) then the interpreter manages cost-centre stacks during
      execution and can produce a stack trace on request.  Call locations
      are available for all interpreted code, and any compiled code that was
      built with the `-fprof-auto` familiy of flags.
      There are a couple of ways to get a stack trace:
      * `error`/`undefined` automatically get one attached
      * `Debug.Trace.traceStack` can be used anywhere, and prints the current
      Because the interpreter is running in a separate process, only the
      interpreted code is running in profiled mode and the compiler itself
      isn't slowed down by profiling.
      The GHCi debugger still doesn't work with -fexternal-interpreter,
      although this patch gets it a step closer.  Most of the functionality
      of breakpoints is implemented, but the runtime value introspection is
      still not supported.
      Along the way I also did some refactoring and added type arguments to
      the various remote pointer types in `GHCi.RemotePtr`, so there's
      better type safety and documentation in the bridge code between GHC
      and ghc-iserv.
      Test Plan: validate
      Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1747
      GHC Trac Issues: #11047, #11100
  6. 04 Jan, 2016 1 commit
  7. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      Reviewed By: bgamari, thomie, ezyang
      Differential Revision: https://phabricator.haskell.org/D1673
  8. 19 Dec, 2015 1 commit
  9. 17 Dec, 2015 4 commits
    • Thomas Miedema's avatar
      Build system: allow bindist without docs · 116ba5e7
      Thomas Miedema authored
      Useful for testing 'make binary-dist-prep' when HADDOCK_DOCS=NO.
      Reviewed by: bgamari
      Differential Revision: https://phabricator.haskell.org/D1648
    • Thomas Miedema's avatar
      Build system: also put scripts in libexecdir/bin · c1bd3d44
      Thomas Miedema authored
      This follows a similar change in
      4905b83a, where binaries are installed
      in libexecdir/bin instead of libexecdir.
      This fixes a problem with ghc not able to find ghc-split, when
    • Simon Marlow's avatar
      Fix libffi dependency, and remove redundant LibFFI.hsc · 27f47cda
      Simon Marlow authored and Simon Marlow's avatar Simon Marlow committed
      LibFFI.hsc was moved to libraries/ghci/GHCi/FFI.hsc, I just forgot to
      remove the old one.  We also need an explicit dependency on libffi,
      which moves from compiler/ghc.mk to the top-level ghc.mk (because
      libraries/ghci/ghc.mk is auto-generated).
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      (Some of this code is derived from GHCJS.)
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      Reaosns we want this:
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that...
  10. 06 Dec, 2015 1 commit
  11. 01 Dec, 2015 1 commit
    • Thomas Miedema's avatar
      Build system: Add stage specific SRC_HC_(WARNING_)OPTS · 14d0f7f1
      Thomas Miedema authored and Herbert Valerio Riedel's avatar Herbert Valerio Riedel committed
      * Add stage specific versions of SRC_HC_OPTS. These are currently only
        used for -Werror. The previous combination of GhcStage2HcOpts and
        GhcLibHcOpts didn't apply to utils/*.
      * Add stage specific versions of SRC_HC_WARNING_OPTS. These will later be
        used for new warning supression flags that should not be passed to the
        bootstrap compiler.
      * Move -Wall (and -Werror) related code back to mk/warnings.mk, where it
        was before 987d5427. Now all warning related code is nicely together.
        Include mk/warnings.mk after mk/custom-settings.mk to make this work.
      Reviewed By: bgamari, hvr
      Differential Revision: https://phabricator.haskell.org/D1536
  12. 16 Nov, 2015 1 commit
  13. 07 Nov, 2015 1 commit
  14. 03 Nov, 2015 1 commit
    • Thomas Miedema's avatar
      Build system: renable -Wall on validate (base) · 987d5427
      Thomas Miedema authored
      Problem: 'SRC_HC_OPTS += -Wall' in 'mk/warnings.mk' was getting
      overwritten by 'SRC_HC_OPTS = ...' in 'mk/flavours/*.mk'.
      It didn't affect the compiler or most other libraries, because most
      .cabal files define 'ghc-options: -Wall'.
      Bug introduced in commit
      2c24fd70, when moving validate settings
      from 'mk/validate-settings.mk' to 'mk/flavours/validate.mk'.
      Reviewed By: austin
      Differential Revision: https://phabricator.haskell.org/D1425
  15. 01 Nov, 2015 1 commit
  16. 30 Oct, 2015 1 commit
  17. 29 Oct, 2015 1 commit
    • Thomas Miedema's avatar
      Revert "Build system: don't create mk/are-validating.mk" · fa587316
      Thomas Miedema authored
      This reverts commit aecf4a5f.
      It turns out the Simons are relying on 'mk/are-validating.mk', see
      The workflow they are using is:
        * run ./validate
        * find a bug in the compiler
        * try to fix the bug, running 'make 1' (or 'make 2') repeatedly. Because
          of 'mk/are-validating.mk', this uses the same build settings as validate.
        * continue ./validate (--no-clean)
      I suggested two alternatives:
        A. run 'make 1 Validating=YES' instead of 'make 1'
           Problem: when running `./validate --fast` or `./validate --hpc`
           instead of a normal `./validate`, validate sets ValidateSpeed and
           ValdateHpc in mk/are-validating.mk. You would for example have to run
           'make 1 Validating=YES ValidateSpeed=FAST' instead of 'make 1' to get the
           same build settings as `./validate --fast`, which is entirely too long and
           error prone.
        B. uncomment `#BuildFlavour=validate` in mk/build.mk, and include
            * any other settings you have in build.mk will also get used.
            * the distinction between 'mk/validate.mk' and 'mk/build.mk' becomes less
            * it is easy to forget to include 'mk/validate.mk'.
            * the build system again doesn't have access to the ValidateSpeed and
              ValdateHpc settings set by validate.
      Neither of these two options is entirely satisfactory.
      Reviewers: austin, bgamari
      Differential Revision: https://phabricator.haskell.org/D1383
  18. 25 Oct, 2015 1 commit
    • Alan Zimmerman's avatar
      Provide a utility to check API Annotations · 43751b24
      Alan Zimmerman authored and Ben Gamari's avatar Ben Gamari committed
      It is difficult for GHC developers to know if they have broken the API
      This patch provides a utility that can be used as a test to show up
      errors in the API Annotations.
      It is based on the current tests for ghc-api/annotations which can parse
      a file using the just-built GHC API, and check that no annotations are
      disconnected from the ParsedSource in the output.
      In addition, it should be able to dump the annotations to a file, so a
      new feature developer can check that all changes to the parser do
      provide annotations.
      Trac ticket: #10917
      Test Plan: ./validate
      Reviewers: hvr, thomie, austin, bgamari
      Reviewed By: bgamari
      Differential Revision: https://phabricator.haskell.org/D1368
      GHC Trac Issues: #10917
  19. 22 Oct, 2015 1 commit
  20. 13 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Make dataToQa aware of Data instances which use functions to implement toConstr · d2f9972a
      Ryan Scott authored
      Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
      freak out if using a `Data` instance that produces a `Constr` (by means of
      `toConstr`) using a function name instead of a data constructor name. While
      such `Data` instances are somewhat questionable, they are nevertheless present
      in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
      aware of their existence.
      In order to properly distinguish strings which represent variables (as opposed
      to data constructors), it was necessary to move functionality from `Lexeme` (in
      `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
      Reviewed By: goldfire, thomie
      Differential Revision: https://phabricator.haskell.org/D1313
      GHC Trac Issues: #10796
  21. 04 Oct, 2015 1 commit
  22. 03 Oct, 2015 2 commits
  23. 08 Sep, 2015 3 commits
    • Thomas Miedema's avatar
      Build system: check for inconsistent settings (#10157) · 1b8eca18
      Thomas Miedema authored
      `configure` currently detects when the docbook and hscolour tools aren't
      available, and instead of failing outright (as it does for missing alex
      and happy), sets some variables in mk/config.mk to tell `make` not to
      build the documentation.
      Sometimes, however, you want to really make sure all documentation gets
      built, fully colourized. For example when making a release. To do so,
      you can override the mentioned variables from mk/config.mk in
      mk/build.mk (e.g. set HSCOLOUR_SRCS=YES).
      This patch adds some error checking to make sure that doing so will not
      result in weird build failures when those tools are still missing.
      Test Plan: ran `make` a couple of times, with different mk/config.mk settings.
      Reviewed by: austin
      Differential Revision: https://phabricator.haskell.org/D1232
    • Thomas Miedema's avatar
      Build system: cleanup BUILD_DIRS + add lots of Notes · 8be43dd9
      Thomas Miedema authored
      See Note [CrossCompiling vs Stage1Only] in mk/config.mk.in.
      See Note [Stage1Only vs stage=1] in mk/config.mk.in.
      See Note [No stage2 packages when CrossCompiling or Stage1Only].
        * use stage2 to build mkUserGuidePart, as was probably intended.
          Now the following represent the same set of packages:
          - packages that we build with ghc-stage2
          - packages that depend on the ghc library
          Those packages are: haddock, mkUserGuidePart and ghctags.
        * don't let utils that don't depend on the ghc library depend on its
          package-data.mk file. Instead, let those utils directly depend on
          the package-data.mk files of the stage1 packages. Not sure if it
          improves anything, but I found it easier to explain what's going on
          this way.
      (partially) reviewed by: austin
      Differential Revision: https://phabricator.haskell.org/D1218
    • Thomas Miedema's avatar
      Build system: delete the InstallExtraPackages variable · a1586074
      Thomas Miedema authored
      Just install all packages that are built. Don't make an exception for
      the dph and extra packages.
      You can control whether the dph and extra packages should be build using
      the variables BUILD_DPH and BUILD_EXTRA_PKGS. These variables didn't
      exist before. But now that they do, InstallExtraPackages isn't really
      needed anymore.
      Reviewed by: austin
      Differential Revision: https://phabricator.haskell.org/D1227
  24. 04 Sep, 2015 1 commit
  25. 21 Aug, 2015 1 commit
  26. 17 Jul, 2015 1 commit
  27. 13 Jul, 2015 3 commits
  28. 02 Jul, 2015 1 commit
  29. 22 Jun, 2015 1 commit
    • Edward Z. Yang's avatar
      Rename $1_$2_$3_LIB_NAME to LIB_FILE. · 01f7e440
      Edward Z. Yang authored
      When we introduced user-friendly library names
      (e.g. unix- 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
      which (confusingly) refers to something like
      'libHSunix-'.  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
  30. 20 Jun, 2015 1 commit
  31. 09 Jun, 2015 1 commit