1. 16 Oct, 2019 1 commit
  2. 15 Oct, 2019 1 commit
  3. 14 Oct, 2019 1 commit
  4. 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
  5. 09 Oct, 2019 2 commits
  6. 08 Oct, 2019 3 commits
  7. 07 Oct, 2019 1 commit
  8. 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.
  9. 03 Oct, 2019 1 commit
  10. 01 Oct, 2019 2 commits
  11. 25 Sep, 2019 1 commit
    • Matthew Pickering's avatar
      Add ghcide configuration files · 218c5dbf
      Matthew Pickering authored
      This commit adds three new files
      1. A hie.yaml file to the project root which specifies to IDEs how to
      set up the correct environment for loading GHC. This currently
      specifies to call the `./hadrian/hie-bios` script.
      2. A `hie.yaml` file for the hadrian subcomponent, which uses the
      `cabal` cradle type.
      2. The `./hadrian/hie-bios` script which supplies the correct arguments
      for an IDE to start a session.
      With these two files it is possible to run
      ghcide compiler/
      and successfully load all the modules for use in the IDE.
      ghcide --cwd hadrian/ src/
      to test loading all of Hadrian's modules.
      Closes #17194
  12. 24 Sep, 2019 2 commits
    • Ben Gamari's avatar
      hadrian: Update source-repository · 6bca867c
      Ben Gamari authored
    • 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.
  13. 23 Sep, 2019 6 commits
  14. 22 Sep, 2019 1 commit
  15. 20 Sep, 2019 2 commits
  16. 16 Sep, 2019 1 commit
  17. 13 Sep, 2019 1 commit
  18. 12 Sep, 2019 1 commit
  19. 11 Sep, 2019 1 commit
  20. 07 Sep, 2019 1 commit
  21. 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.
  22. 02 Sep, 2019 1 commit
  23. 22 Aug, 2019 1 commit
  24. 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
  25. 07 Aug, 2019 1 commit
    • 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