1. 03 Nov, 2019 1 commit
  2. 17 Apr, 2019 1 commit
    • Alp Mestanogullari's avatar
      Hadrian: introduce ways to skip some documentation targets · 4e734059
      Alp Mestanogullari authored
      The initial motivation for this is to have a chance to run the binary
      distribution rules in our Windows CI without having to install
      sphinx-build and xelatex there, while retaining the ability to
      generate haddocks. I just ended up extending this idea a little bit so
      as to have control over whether we build haddocks, (sphinx) HTML manuals,
      (sphinx) PDF manuals and (sphinx) manpages.
      
      (cherry picked from commit 8442103a)
      4e734059
  3. 20 Feb, 2019 3 commits
    • Gabor Greif's avatar
      A few typofixes · 9c09935a
      Gabor Greif authored
      9c09935a
    • Alec Theriault's avatar
      Hadrian: install patches 'haddock-{html,interface}' · 59a8d475
      Alec Theriault authored
      Since the `$(docdir)` can be picked independently from the `$(libdir)`,
      we need to make sure that that the `haddock-html` and `haddock-interface`
      fields in the package DB (which is in the `$(libdir)`) get updated to
      point to the appropriate places in the `$(docdir)`.
      
      NB: in the make system, `ghc-cabal` would cover this sort of thing by
      re-running `configure` on installation, but here we get away with a
      couple lines of `sed` and a call to `ghc-pkg recache`.
      
      Fixes #16202.
      59a8d475
    • Matthew Pickering's avatar
      Fix hadrian prof flavour so that it builds a profiled version of GHC · 49c1f88c
      Matthew Pickering authored
      In Alp's refactoring of `getProgramContexts` he removed a call to
      `getProgramContext` which was where the logic for this used to be
      implemented.
      
      Fixes #16214
      49c1f88c
  4. 16 Jan, 2019 5 commits
  5. 14 Jan, 2019 1 commit
    • Herbert Valerio Riedel's avatar
      Update `Cabal` submodule · cb31b23d
      Herbert Valerio Riedel authored
      This also requires adapting `ghc-pkg` to use the new Cabal parsing API
      as the old ReadP-based one has finally been evicted for good.
      
      Hadrian bit finished by: Ben Gamari <ben@smart-cactus.org>
      cb31b23d
  6. 09 Jan, 2019 1 commit
    • Matthew Pickering's avatar
      Hadrian: Add support for building stage3 · 6486c6e4
      Matthew Pickering authored
      This ticket enables the building of a `stage3` compiler by making the
      build logic more consistent and predictable in Hadrian.
      
      Two of the main changes are:
      
      1. In order to build anything at stageN we use the package database
      present at stageN. Fixing #16069
      2. `haddock` and `ghc-tags` are built
      as stage1 executables (with the stage1 compiler) rather than as
      stage2 compiler. Fixing
      [hadrian#661](https://github.com/snowleopard/hadrian/issues/661)
      
      In order to build a stage3 compiler, you have to set the new `finalStage` hadrian option to `Stage3`.
      6486c6e4
  7. 06 Jan, 2019 1 commit
    • Zejun Wu's avatar
      Hadrian: merge sections in profiling _p.a to .p_o for ghci · 9ea8dcea
      Zejun Wu authored
      This is the hadrain version of {D5169}
      
      * We build squashed .o and .p_o for ghci when `dynamicGhcPrograms` is
      `False`
      * We no longer build them for rts as ghci never loads it
      
      we need https://github.com/haskell/cabal/pull/5592 for cabal to copy
      the built `.p_o` file.
      
      Test Plan:
      ```
      $ grep dynamicGhc hadrian/UserSettings.hs
        , dynamicGhcPrograms = return False
      $ touch ...
      $ hadrian/build.sh --flavour=user -j --digest-or
      $ find _build/stage1/libraries/ -name 'HS*-*.*o' | wc
           62      62    3664
      ```
      
      ```
      $ grep -C3 dynamicGhc hadrian/UserSettings.hs
      userFlavour :: Flavour
      userFlavour = performanceFlavour
        { name = "user"
        , dynamicGhcPrograms = return False
        }
      $ hadrian/build.sh -j --flavour=user test --verbose
      Unexpected results from:
      TEST="T3807 T9208 T9293 annth_make ghci057 haddock.Cabal haddock.base
      haddock.compiler"
      
      SUMMARY for test run started at Wed Dec  5 17:45:39 2018 PST
       0:03:16 spent to go through
          6708 total tests, which gave rise to
         26015 test cases, of which
         19290 were skipped
      
            29 had missing libraries
          6600 expected passes
            88 expected failures
      
             3 caused framework failures
             0 caused framework warnings
             1 unexpected passes
             7 unexpected failures
             0 unexpected stat failures
      $ find _build -name 'HSbase*.*o'
      _build/stage1/lib/x86_64-linux-ghc-8.7.20181204/base-4.12.0.0/HSbase-4.1
      2.0.0.o
      _build/stage1/lib/x86_64-linux-ghc-8.7.20181204/base-4.12.0.0/HSbase-4.1
      2.0.0.p_o
      _build/stage1/libraries/base/build/HSbase-4.12.0.0.o
      _build/stage1/libraries/base/build/HSbase-4.12.0.0.p_o
      ```
      
      Reviewers: bgamari, simonmar, snowleopard
      
      Reviewed By: snowleopard
      
      Subscribers: alpmestan, rwbarton, carter
      
      GHC Trac Issues: #15779
      
      Differential Revision: https://phabricator.haskell.org/D5270
      9ea8dcea
  8. 11 Dec, 2018 2 commits
    • Alp Mestanogullari's avatar
      Hadrian: simple targets for building libraries and executables · 7491cedb
      Alp Mestanogullari authored
      This patch introduces (phony) build targets of the form
      
          (1) stage<N>:<lib>:<name>   (e.g: stage1:lib:Cabal)
          (2) stage<N>:<exe>:<name>   (e.g: stage2:exe:ghc-bin)
      
      where (1) builds the given library with the stage N compiler and (2)
      builds the given executable with the stage N-1 compiler. This patch may
      be generating too many such targets but it's a first stab that we can
      refine.
      
      This fixes #15949.
      
      Test Plan: hadrian/build.sh stage1:exe:ghc-bin
      
      Reviewers: bgamari, snowleopard
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15949
      
      Differential Revision: https://phabricator.haskell.org/D5434
      7491cedb
    • David Eichmann's avatar
      Revert dynamically linking ghc. · 4efafe7e
      David Eichmann authored
      Building a dynamically linked ghc is broken do to incorrectly building
      and installing libffi. This disables building a dynamically linked ghc
      and ghc-iserv-dyn while keeping most of the code in the relevant
      commits: 79d5427e and 89fa34ec
      
      Test Plan:
      Ensure build environment does NOT have a system libffi installed (you
      may want to use a nix environment).
      Then `hadrian/build.sh -c --flavour=default`.
      
      Reviewers: bgamari, alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15837
      
      Differential Revision: https://phabricator.haskell.org/D5430
      4efafe7e
  9. 08 Dec, 2018 1 commit
    • Alp Mestanogullari's avatar
      hadrian: eliminate most of the remaining big rule enumerations · 665f8b0c
      Alp Mestanogullari authored
      Following what was done to Rules.Library some time ago and to
      Rules.Compile recently (D5412), this patch moves more rules away from
      the "enumerate a lot of contexts and generate one rule for each" style
      and instead uses the "parse data from file path to recover context"
      approach. In fact, the only rules left to convert seem to be the ones
      from Rules.Generate.
      
      This effectively decreases the pauses described in #15938 further as
      well as the amount of allocations and GC that we do, unsurprisingly.
      Nowhere as drastically as D5412, though.
      
      Test Plan: perform full build and generate docs
      
      Reviewers: snowleopard, bgamari
      
      Reviewed By: snowleopard
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15938
      
      Differential Revision: https://phabricator.haskell.org/D5422
      665f8b0c
  10. 07 Dec, 2018 1 commit
    • Alp Mestanogullari's avatar
      hadrian: optimise Rules.Compile · eee1b61f
      Alp Mestanogullari authored
      Previously, as reported in #15938, resuming a build "in the middle",
      e.g when building _build/stage1/libraries/base/, hadrian would take up
      to a whole minute to get started doing actual work, building code.
      
      This was mostly due to a big enumeration that we do in Rules.hs, to
      generate all the possible patterns for object files for 1) all ways, 2)
      all packages and 3) all stages. Since rule enumeration is always
      performed, whatever the target, we were always paying this cost, which
      seemed to grow bigger the farther in the build we stopped and were
      resuming from.
      
      Instead, this patch borrows the approach that we took for Rules.Library
      in https://github.com/snowleopard/hadrian/pull/571, which exposes all the
      relevant object files under as few catch-all rules as possible (8 here),
      and parses all the information we need out of the object's path.
      
      The concrete effect of this patch that I have observed is to reduce the
      45-60 seconds pause to <5 seconds. Along with the Shake performance
      improvements that Neil mentions in #15938, most of the pause should
      effectively disappear.
      
      Reviewers: snowleopard, bgamari, goldfire
      
      Reviewed By: snowleopard
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15938
      
      Differential Revision: https://phabricator.haskell.org/D5412
      eee1b61f
  11. 04 Dec, 2018 1 commit
    • Alec Theriault's avatar
      Hadrian: include 'findPtr' via find-ptr cabal flag · 924026e0
      Alec Theriault authored
      Summary:
      This is the latest in the 'findPtr' saga. See
      
        * 900c47f8
        * 561748cb
      
      for the previous attempts. The problem with re-using the 'debug'
      cabal flag for the purpose of forcing inclusion of 'findPtr' occurs
      when 'debug' is one of the RTS ways, but RTS is not being compiled
      with '-DDEBUG':
      
        * the 'debug' flag gets passed to cabal, signalling to build
          'rts' with the debug flavour, but also forcing inclusion of
          the 'findPtr'/'_findPtr' symbol
      
        * since '-DDEBUG' isn't enabled, that symbol doesn't show up in
          the libraries, so executable that depend on 'rts' (everything)
          will end up always requiring 'findPtr'/'_findPtr' but 'rts' won'y
          provide it!
      
      The fix is simple: create a a new 'find-ptr' cabal-flag whose only
      purpose is forcing '-Wl,-u,findPtr'/'-Wl,-u,_findPtr'. Then, enable that
      flag when the RTS is being compiled with '-DDEBUG'
      
      Test Plan: ./hadrian/build.sh -c # on mac
      
      Reviewers: alpmestan, snowleopard, bgamari, erikd, simonmar, Phyx
      
      Reviewed By: alpmestan, snowleopard, Phyx
      
      Subscribers: Phyx, rwbarton, carter
      
      GHC Trac Issues: #15956
      
      Differential Revision: https://phabricator.haskell.org/D5404
      924026e0
  12. 01 Dec, 2018 2 commits
  13. 29 Nov, 2018 1 commit
    • Alp Mestanogullari's avatar
      Hadrian: bump Cabal submodule, install extra dynamic flavours of RTS · fb997160
      Alp Mestanogullari authored
      Previously, Hadrian was building all the appropriate dynamic ways for
      libHSrts
      but they were not picked up and installed in the package database when
      we register the rts library. Since we use Cabal for registering
      packages and
      the .cabal files of packages as sources of truth for configuring and
      installing,
      we ended up patching Cabal to add a new field,
      'extra-dynamic-library-flavours',
      to specify those extra flavours to install in .cabal files:
      
          https://github.com/haskell/cabal/pull/5606
      
      We now make use of this in rts.cabal.in to expose dynamic flavours
      behind a
      Cabal flag, which Hadrian will use whenever we are building a GHC
      flavour that
      requires dynamic libraries.
      
      This is all part of a larger plan to build a dynamic stage 2 GHC by
      default,
      like with make, which in turn will fix a lot of test failures. See
      
      Test Plan:
      hadrian/build.sh _build/stage1/lib/package.conf.d/rts-1.0.conf
      _build/stage1/lib/x86_64-.../ should contain many libHSrts-*.so
      
      Reviewers: snowleopard, DavidEichmann, bgamari, erikd, simonmar
      
      Reviewed By: snowleopard, DavidEichmann
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15837
      
      Differential Revision: https://phabricator.haskell.org/D5385
      fb997160
  14. 27 Nov, 2018 1 commit
    • Alp Mestanogullari's avatar
      Hadrian: improve bindist rule · 8f52ab92
      Alp Mestanogullari authored
      As outlined in #15925, hadrian bindists had not made a clear choice with
      respect to relocatable GHCs and wrapper scripts. This commit implements
      the policy described in the ticket. That is:
      
      - the bindists ship {bin, lib} as they are, modulo the addition of
        haddock from stage2/bin
      - we now _always_ generate wrapper scripts for all the programs that
        are in the bindist's bin/ directory
      
      The idea being that anyone on Linux/Windows/OS X can just unpack
      the binary distribution anywhere and start using bin/ghc, while the
      installation process systematicaly generates wrapper scripts.
      
      Test Plan: hadrian/build.sh binary-dist ; cd
      _build/bindist/ghc-X.Y.Z-arch/; configure --prefix=/tmp/foo && make
      install
      
      Reviewers: snowleopard, bgamari, angerman
      
      Reviewed By: snowleopard, bgamari, angerman
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15925
      
      Differential Revision: https://phabricator.haskell.org/D5371
      8f52ab92
  15. 22 Nov, 2018 2 commits
    • Alec Theriault's avatar
      Hadrian: Misc. fixes in Haddock rules · ff619555
      Alec Theriault authored
      * Pass 'GHC/Prim.hs' to Haddock when processing 'ghc-prim'. This
        file is autogenerated for the sole purpose of giving Haddock
        something to process, so we really should make sure it gets
        through to Haddock!
      
      * Add a "docs-haddock" build rule, which should build all Haddock docs
        that the Makefile builds by default (all libs + index for libs + ghc)
      
      * Prune some unnecessary rules (esp. `gen_contents_index`)
      
      Reviewers: bgamari, snowleopard
      
      Reviewed By: snowleopard
      
      Subscribers: alpmestan, snowleopard, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5316
      ff619555
    • Alec Theriault's avatar
      Hadrian: work around Cabal's/GHC's different Arch/OS strings · 19ffddc1
      Alec Theriault authored
      The path to the 'include' subdirectory of 'rts' includes a folder that
      whose name is generated by Cabal and mentiones the architecture and OS.
      For example:
      
          _build/stage1/lib/x86_64-osx-ghc-8.7.20181120/rts-1.0/include
      
      Hadrian needs to be aware that Cabal renders architectures and OSes in
      a slightly different way than GHC. There is already symmetric logic in
      Cabal (for working with GHC environment files, which follow GHC's naming
      conventions).
      
      Test Plan: ./hadrian/build.sh -c "binary-dist" # on mac
      
      Reviewers: snowleopard, alpmestan, bgamari
      
      Reviewed By: snowleopard
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15922
      
      Differential Revision: https://phabricator.haskell.org/D5361
      19ffddc1
  16. 19 Nov, 2018 1 commit
    • Alp Mestanogullari's avatar
      hadrian: make it possible to run the testsuite with quickest and quick · cc615c69
      Alp Mestanogullari authored
      More generally, we so far assumed that the testsuite would be executed
      with a flavour that's as comprehensive as perf in terms of available RTS
      and library flavours (at least vanilla + dynamic + prof). This would
      manifest itself concretely by needing 3 "ways" of the iserv program,
      unconditionally.
      
      We now only require the ways among vanilla, dynamic and prof that we
      can find in our current Flavour's rtsWays.
      
      Test Plan:
      hadrian/build.sh --flavour={quick, quickest} test now goes through
      (with a few failing tests, of course).
      
      Reviewers: bgamari, tdammers
      
      Reviewed By: tdammers
      
      Subscribers: mpickering, RyanGlScott, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5355
      cc615c69
  17. 14 Nov, 2018 1 commit
  18. 01 Nov, 2018 1 commit
    • Alp Mestanogullari's avatar
      hadrian: build ghc-iserv-prof in addition to ghc-iserv · 695f1f2f
      Alp Mestanogullari authored
      As it is required for 10+ tests.
      
      Hadrian didn't give us a chance to build a given executable in vanilla
      and profiling, simultaneously, under two different names. This patch
      implements support for this in general and applies it to
      ghc-iserv[-prof].
      
      Test Plan: scc001 fails without this patch, passes with it.
      
      Reviewers: snowleopard, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, ndmitchell, simonmar, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5255
      695f1f2f
  19. 08 Dec, 2017 1 commit