1. 16 Oct, 2019 1 commit
  2. 15 Oct, 2019 1 commit
  3. 12 Oct, 2019 2 commits
    • John Ericson's avatar
      Simplify Configure in a few ways · c2290596
      John Ericson authored
       - No need to distinguish between gcc-llvm and clang. First of all,
         gcc-llvm is quite old and surely unmaintained by now. Second of all,
         none of the code actually care about that distinction!
         Now, it does make sense to consider C multiple frontends for LLVMs in
         the form of clang vs clang-cl (same clang, yes, but tweaked
         interface). But this is better handled in terms of "gccish vs
         mvscish" and "is LLVM", yielding 4 combinations. Therefore, I don't
         think it is useful saving the existing code for that.
       - Get the remaining CC_LLVM_BACKEND, and also TABLES_NEXT_TO_CODE in
         mk/config.h the normal way, rather than hacking it post-hoc. No point
         keeping these special cases around for now reason.
       - Get rid of hand-rolled `die` function and just use `AC_MSG_ERROR`.
       - Abstract check + flag override for unregisterised and tables next to
      Oh, and as part of the above I also renamed/combined some variables
      where it felt appropriate.
       - GccIsClang -> CcLlvmBackend. This is for `AC_SUBST`, like the other
       Camal case ones. It was never about gcc-llvm, or Apple's renamed clang,
       to be clear.
       - llvm_CC_FLAVOR -> CC_LLVM_BACKEND. This is for `AC_DEFINE`, like the
       other all-caps snake case ones. llvm_CC_FLAVOR was just silly
       indirection *and* an odd name to boot.
    • Stefan Schulze Frielinghaus's avatar
  4. 09 Oct, 2019 2 commits
  5. 08 Oct, 2019 3 commits
  6. 05 Oct, 2019 4 commits
    • John Ericson's avatar
      Always enable the external interpreter · 0dded5ec
      John Ericson authored
      You can always just not use or even build `iserv`. I don't think the
      maintenance cost of the CPP is worth...I can't even tell what the
      benefit is.
    • John Ericson's avatar
    • John Ericson's avatar
      Remove {Build,Host}Platform_NAME from header · 75a5dd8e
      John Ericson authored
      They are only used in a file we construct directly, so just skip CPP.
    • John Ericson's avatar
      Per stage headers, ghc_boot_platform.h -> stage 0 ghcplatform.h · 05419e55
      John Ericson authored
      The generated headers are now generated per stage, which means we can
      skip hacks like `ghc_boot_platform.h` and just have that be the stage 0
      header as proper. In general, stages are to be embraced: freely generate
      everything in each stage but then just build what you depend on, and
      everything is symmetrical and efficient. Trying to avoid stages because
      bootstrapping is a mind bender just creates tons of bespoke
      mini-mind-benders that add up to something far crazier.
      Hadrian was pretty close to this "stage-major" approach already, and so
      was fairly easy to fix. Make needed more work, however: it did know
      about stages so at least there was a scaffold, but few packages except
      for the compiler cared, and the compiler used its own counting system.
      That said, make and Hadrian now work more similarly, which is good for
      the transition to Hadrian. The merits of embracing stage aside, the
      change may be worthy for easing that transition alone.
  7. 03 Oct, 2019 1 commit
  8. 01 Oct, 2019 2 commits
  9. 24 Sep, 2019 1 commit
    • Takenobu Tani's avatar
      Hadrian: Add -haddock option for GHCi's :doc command · b5f24fb4
      Takenobu Tani authored
      This commit adds -haddock option to Hadrian-based build system.
      To enable :doc command on GHCi, core libraries must be compiled
      with -haddock option.
      Especially, the `-haddock` option is essential for a release build.
      Assuming current GitLab CI condition (.gitlab-ci.yml),
      I add -haddock option to the default flavour only.
      This has already been done for Make-based build system.
      Please see #16415.
  10. 23 Sep, 2019 6 commits
  11. 22 Sep, 2019 1 commit
  12. 13 Sep, 2019 1 commit
  13. 07 Sep, 2019 1 commit
  14. 05 Sep, 2019 1 commit
    • John Ericson's avatar
      Make sure all boolean settings entries use `YES` / `NO` · b55ee979
      John Ericson authored
      Some where using `True` / `False`, a legacy of when they were in
      `Config.hs`. See #16914 / d238d306 for a similar problem.
      Also clean up the configure variables names for consistency and clarity
      while we're at it. "Target" makes clear we are talking about outputted
      code, not where GHC itself runs.
  15. 02 Sep, 2019 1 commit
  16. 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
      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
  17. 07 Aug, 2019 1 commit
    • 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
  18. 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.
  19. 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.
    • 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.
  20. 20 Jul, 2019 1 commit
  21. 19 Jul, 2019 2 commits
  22. 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.
  23. 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`.
  24. 14 Jul, 2019 2 commits