1. 22 Aug, 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. 07 Aug, 2019 2 commits
    • Matthew Pickering's avatar
      Remove old/broken(?) .ghci script · c83e39bf
      Matthew Pickering authored
      I was attempting to load hadrian into ghci by using
      `cabal new-repl exe:hadrian` but it failed because it tried
      to use this `.ghci` configuration.
      
      I'm not sure who used this script but you should really use the new-repl
      method.
      c83e39bf
    • James Foster's avatar
      hadrian: Refactor file patterns for future Shake changes (fixes #17005) · 0c1ccf3c
      James Foster authored
      Shake will be moving from its current implementation of ?== to one from
      System.FilePattern. Support for `//` is being dropped, leaving only `*`
      and `**` as special forms. This commit converts the existing file
      patterns in Hadrian to the new format. It also removes all occurances
      of <//> and changes the user-settings docs to remove references to //
      and add **.
      
      The conversion is as follows:
      
      - //a ==> **/a
      
      - a// ==> a/**
      
      - a//b ==> a/**/b
      0c1ccf3c
  4. 03 Aug, 2019 1 commit
    • Alp Mestanogullari's avatar
      Hadrian: make settings, platformConstants, etc dependencies of lib:ghc · a5227080
      Alp Mestanogullari authored
      This fixes #17003, where a user directly asked for the 'docs-haddock' target
      without building a complete stage 2 GHC first. Since haddock only depends on
      lib:ghc, the stage 2 GHC executable wasn't built, and neither were the
      settings, platformConstants, llvm-passes and llvm-targets files, since they
      are declared to be dependencies of exe:ghc.
      
      This makes sense in general since all GHC API users (haddock is one) will likely
      want those files to be there.
      a5227080
  5. 29 Jul, 2019 1 commit
  6. 28 Jul, 2019 1 commit
  7. 24 Jul, 2019 2 commits
    • John Ericson's avatar
      Make stage 1 GHC target independent · b95b6380
      John Ericson authored
      Now that the target macros are not being used, we remove them. This
      prevents target hardcoding regressions.
      b95b6380
    • Alp Mestanogullari's avatar
      Hadrian: run the testsuite in Windows CI job · 6ade71fb
      Alp Mestanogullari authored
      Since MR !1025 fixed the Windows build, allowing us to build a binary
      distribution, we can now run the testsuite in that CI job.
      
      This required fixing 'createFileLink': it should not try to create
      symlinks on Windows (that requires admin priviledges, which Hadrian can't
      assume). We now instead fall back to copying.
      
      This patch also removes some duplicated logic for iserv in the test rules,
      where we handle our dependency on the iserv binaries in a special way.
      6ade71fb
  8. 20 Jul, 2019 1 commit
  9. 19 Jul, 2019 2 commits
  10. 17 Jul, 2019 1 commit
    • Sebastian Graf's avatar
      Make GHC-in-GHCi work on Windows · 8add024f
      Sebastian Graf authored
      By not building anything in the dynamic way on Windows, where we don't
      have a working story for DLLs yet.
      
      Also the ghcid command needs to call bash on the hadrian/ghci.sh script
      explicitly as the path gets interpreted differently otherwise.
      8add024f
  11. 16 Jul, 2019 1 commit
    • Artem Pelenitsyn's avatar
      Sort out Hadrian colored output flags (fix #16397) · 5728d9fa
      Artem Pelenitsyn authored
      Hadrian used to have a separate flag --progress-colour to control
      colored output during the build. After introduction of a Shake flag
      with similar purpose Hadrian's flag became redundant. The commit removes
      --progress-colour and switches to Shake's flag. The only difference
      between the two is that Hadrian has special default mode when it tries
      to determine if the terminal support colored output. The user can
      override it using (Shake's) `--[no-]color`.
      5728d9fa
  12. 14 Jul, 2019 2 commits
  13. 13 Jul, 2019 1 commit
  14. 12 Jul, 2019 1 commit
  15. 10 Jul, 2019 5 commits
    • Ben Gamari's avatar
      hadrian/doc: Add some discussion of compilation stages · a35e0916
      Ben Gamari authored
      This documents some of the lore surrounding the nature and naming of
      GHC's stage numbers.
      a35e0916
    • Alp Mestanogullari's avatar
      Hadrian: fix source-dist rule · 7f8bf98e
      Alp Mestanogullari authored
      The first problem was that the list of files/dirs to embed or ignore was not
      up-to-date. The second problem was that the 'Cwd' option used when running the
      Tar builder in the source-dist rule didn't actually change the current directory
      and was therefore failing. Finally, the source-dist rule did not pre-generate
      Haskell modules derived from .x (alex) and .y (happy) files, like the Make
      build system does -- this is now fixed.
      
      We might be doing too much work for that last step (we seem to be building
      many things until we get to generating the source distribution), but extracting
      the distribution and running
      
          ./configure && hadrian/build.sh --flavour=quickest -j
      
      from there does work for me now.
      7f8bf98e
    • Alp Mestanogullari's avatar
      Hadrian: implement key-value settings for builder options · 18ac9ad4
      Alp Mestanogullari authored
      They take the general form `foo.bar.baz [+]= some values`, where
      `=` completely overrides the arguments for a builder and `+=` extends
      them. We currenly only support settings for updating the GHC and C
      compiler options, of the form:
      
      ```
        {stage0, ..., stage3 or *}.{package name or *}
                                  .ghc.{c, hs, link, deps, toolargs or *}.opts
      
        {stage0, ..., stage3 or *}.{package name or *}
                                  .cc.{c, deps or *}.opts
      ```
      
      The supported settings and their use is covered in the new section
      of `hadrian/doc/user-settings.md`, while the implementation is explained
      in a new Note [Hadrian settings].
      
      Most of the logic is implemented in a new module, `Settings.Parser`, which
      contains key-value assignment/extension parsers as well as utilities for
      specifying allowed settings at a high-level, generating a `Predicate` from
      such a description or generating the list of possible completions for a given
      string.
      
      The additions to the `Settings` module make use of this to describe the
      settings that Hadrian currently supports, and apply all such
      key-value settings (from the command line and `<root>/hadrian.settings`)
      to the flavour that Hadrian is going to proceed with.
      
      This new setting system comes with support for generating Bash completions,
      implemented in `hadrian/completion.sh` and Hadrian's `autocomplete` target:
      
      > source hadrian/completion.sh
      > hadrian/build.sh stage1.base.ghc.<TAB>
      stage1.base.ghc.c.opts     stage1.base.ghc.hs.opts
      stage1.base.ghc.*.opts     stage1.base.ghc.deps.opts
      stage1.base.ghc.link.opts  stage1.base.ghc.toolargs.opts
      18ac9ad4
    • John Ericson's avatar
      Deduplicate "unique subdir" code between GHC and Cabal · 24782b89
      John Ericson authored
      The code, including the generated module with the version, is now in
      ghc-boot. Config.hs reexports stuff as needed, ghc-pkg doesn't need any
      tricks at all.
      24782b89
    • John Ericson's avatar
      Remove most uses of TARGET platform macros · 0472f0f6
      John Ericson authored
      These prevent multi-target builds. They were gotten rid of in 3 ways:
      
      1. In the compiler itself, replacing `#if` with runtime `if`. In these
      cases, we care about the target platform still, but the target platform
      is dynamic so we must delay the elimination to run time.
      
      2. In the compiler itself, replacing `TARGET` with `HOST`. There was
      just one bit of this, in some code splitting strings representing lists
      of paths. These paths are used by GHC itself, and not by the compiled
      binary. (They are compiler lookup paths, rather than RPATHS or something
      that does matter to the compiled binary, and thus would legitamentally
      be target-sensative.) As such, the path-splitting method only depends on
      where GHC runs and not where code it produces runs. This should have
      been `HOST` all along.
      
      3. Changing the RTS. The RTS doesn't care about the target platform,
      full stop.
      
      4. `includes/stg/HaskellMachRegs.h` This file is also included in the
      genapply executable. This is tricky because the RTS's host platform
      really is that utility's target platform. so that utility really really
      isn't multi-target either. But at least it isn't an installed part of
      GHC, but just a one-off tool when building the RTS. Lying with the
      `HOST` to a one-off program (genapply) that isn't installed doesn't seem so bad.
      It's certainly better than the other way around of lying to the RTS
      though not to genapply. The RTS is more important, and it is installed,
      *and* this header is installed as part of the RTS.
      0472f0f6
  16. 08 Jul, 2019 1 commit
    • David Eichmann's avatar
      Bump Shake and copy instead of hard link from cloud cache · 03f5adcd
      David Eichmann authored
      This is important as in hard link mode shake  makes all such files
      read only to avoid accidentally modifying cache files via the
      hard link. It turns out, many Hadrian rules attempt read access
      to such files and hence fail in the hard link mode. These
      rules could be refactored to avoid write access, but using
      copy instead of hard link a much simpler solution.
      03f5adcd
  17. 02 Jul, 2019 1 commit
  18. 27 Jun, 2019 1 commit
  19. 26 Jun, 2019 1 commit
  20. 25 Jun, 2019 1 commit
    • Andrey Mokhov's avatar
      Fix cyclic dependencies when using --configure · 15b26223
      Andrey Mokhov authored
      This resolves #16809 (ghc/ghc#16809).
      
      This patch removes the unnecessary dependency on configure-generated
      flags `windowsHost`, `osxHost` and `iosHost`, using the information
      provided by the module `System.Info` instead.
      
      We also take care to use the `CrossCompiling` flag generated by the
      configure script only after the latter had a chance to run.
      15b26223
  21. 18 Jun, 2019 1 commit
    • Ben Gamari's avatar
      hadrian: Compile UserSettings with -O0 · a491e40c
      Ben Gamari authored
      This guarantees that the interface file for `UserSettings` doesn't 
      contain any unfoldings, ensuring that a change in it requires minimal 
      rebuilds.
      a491e40c
  22. 16 Jun, 2019 2 commits
  23. 14 Jun, 2019 2 commits
    • Alp Mestanogullari's avatar
      Hadrian: remove superfluous dependencies in Rules.Compile · ec25fe59
      Alp Mestanogullari authored
      Each package's object files were 'need'ing the library files of all transitive
      dependencies of the current package, whichi is pointless since the said
      libraries are not needed until we link those object files together.
      
      This fixes #16759.
      ec25fe59
    • Ben Gamari's avatar
      Maintain separate flags for C++ compiler invocations · 7bc5d6c6
      Ben Gamari authored
      Previously we would pass flags intended for the C compiler to the C++
      compiler (see #16738). This would cause, for instance, `-std=gnu99` to
      be passed to the C++ compiler, causing spurious test failures. Fix this
      by maintaining a separate set of flags for C++ compilation invocations.
      7bc5d6c6
  24. 13 Jun, 2019 1 commit
  25. 12 Jun, 2019 2 commits
  26. 11 Jun, 2019 3 commits
    • Alp Mestanogullari's avatar
      testsuite/mk/boilerplate.mk: rename 'ghc-config-mk' to 'ghc_config_mk' · aad6115a
      Alp Mestanogullari authored
      Make/shell variable names which contain dashes can cause problems under
      some conditions. The 'ghc-config-mk' variable from testsuite/mk/boilerplate.mk
      that I made overridable (by Hadrian) in ba0aed2e was working as expected when
      our Hadrian/Linux job was based off the deb8 Docker image, but broke when
      I switched the job to use our deb9-based image, in 3d97bad6. The exact
      circumstances/tool versions that trigger this problem are unknown, but
      changing the variable's name to 'ghc_config_mk' lets us work around the issue.
      
      This fixes the annth_compunits and annth_make test failures that showed up
      when we switched the Hadrian/Linux job to use the deb9 environment.
      aad6115a
    • Alp Mestanogullari's avatar
      Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETER · 39f50bff
      Alp Mestanogullari authored
      As discussed in #16331, the GHCI macro, defined through 'ghci' flags
      in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate
      whether GHC is built with support for an internal interpreter, that runs in
      the same process. It is however overloaded in a few places to mean
      "there is an interpreter available", regardless of whether it's an internal
      or external interpreter.
      
      For the sake of clarity and with the hope of more easily being able to
      build stage 1 GHCs with external interpreter support, this patch splits
      the previous GHCI macro into 3 different ones:
      
      - HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter
      - HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters
      - HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
      39f50bff
    • David Eichmann's avatar
      Refactor the rules for .hi and .o into a single rule using `&%>` #16764 · 58a5d728
      David Eichmann authored
      Currently the rule for .hi files just triggers (via need) the rule
      for the .o file, and .o rule generates both the .o and .hi file.
      Likewise for .o-boot and .hi-boot files. This is a bit of an abuse
      of Shake, and in fact shake supports rules with multiple output
      with the &%> function. This exact use case appears in Neil
      Mitchell's paper *Shake Before Building* section 6.3.
      58a5d728
  27. 09 Jun, 2019 1 commit