summaryrefslogtreecommitdiff
path: root/hadrian
Commit message (Collapse)AuthorAgeFilesLines
* Hadrian: compile libgmp static on WindowsTamar Christina2019-02-081-0/+3
|
* Add werror function to Flavour.hsMatthew Pickering2019-02-033-1/+22
| | | | | This function makes it easy to turn on `-Werror` in the correct manner to mimic how CI turns on -Werror.
* Update user-settings.md with a pointer to `Packages`Sebastian Graf2019-02-021-1/+5
| | | [skip ci]
* Hadrian: Fix outdated link.Andrey Mokhov2019-01-311-1/+1
|
* Hadrian: Update instructions for building on WindowsAndrey Mokhov2019-01-312-24/+25
| | | | | | The `hadrian/doc/windows.md` file has falled out of date. In particular it still points to the old GitHub repository, and uses incorrect path to GHC. This patch fixes it.
* Add O2 to hsCompiler on stage0 for most hadrian flavours.klebinger.andreas@gmx.at2019-01-316-10/+10
|
* Only build vanilla way in devel2 flavourMatthew Pickering2019-01-301-1/+4
| | | | Fixes #16210
* Avoid compiling Hadrian dependencies with profiling on Cabal/LinuxNeil Mitchell2019-01-301-1/+1
|
* Avoid compiling Hadrian dependencies with profiling on Cabal/WindowsNeil Mitchell2019-01-301-1/+1
|
* Revert "Batch merge"Ben Gamari2019-01-303-6/+3
| | | | This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
* Batch mergeBen Gamari2019-01-303-3/+6
|
* hadrian: use new-exec to make sure alex & happy are in PATH (#16120)Adam Sandberg Eriksson2019-01-273-2/+8
|
* A few typofixesGabor Greif2019-01-231-1/+1
|
* Hadrian: support in-tree GMPAlec Theriault2019-01-236-11/+17
| | | | | | | | | | | | | | | | | | | | | | Summary: This adds top-level configure flags '--with-intree-gmp' and '--with-framework-preferred', both of which are especially relevant on MacOS. Besides gaining two new flags, Hadrian also had to be taught what to do with the 'framework' in .cabal files. Test Plan: ./boot && ./configure --with-intree-gmp && ./hadrian/build.sh ./boot && ./configure --with-gmp-framework-preferred && ./hadrian/build.sh # on macos Reviewers: carter, snowleopard, alpmestan, hvr, goldfire, bgamari Subscribers: rwbarton, erikd GHC Trac Issues: #16001 Differential Revision: https://phabricator.haskell.org/D5417
* Hadrian: install patches 'haddock-{html,interface}'Alec Theriault2019-01-231-0/+22
| | | | | | | | | | | | | 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.
* Fix hadrian prof flavour so that it builds a profiled version of GHCMatthew Pickering2019-01-231-2/+9
| | | | | | | | 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
* Make sure 'haddock' package also copies resourcesAlec Theriault2019-01-166-34/+31
| | | | ...and does so in the lib folder of the right stage
* Hadrian: handle Haddock's resource directoryAlec Theriault2019-01-163-18/+29
| | | | | | | | | | | | | | | | Fixes #16105 * Require Haddock's resource as runtime dependencies of the Haddock builder. This means we no longer have to `need` particular resources in every other documentation rule. * Do a _tracked_ copy of both the 'html' and 'latex' folder resource folders. * Move resources into `stage1/lib` (NB: the `haddock` binary goes in `stage1/bin`). Besides now actually matching the Haddock script wrapper generated by BinaryDist, this also prepares for Haddock in relocatable build folder detecting its own resources.
* Hadrian: Use the Cabal build script on Windows by defaultAndrey Mokhov2019-01-161-4/+2
| | | | | | | | | | | | | The Stack build script `build.stack.bat` currently fails on Windows when invoked with the `--configure` flag, see: https://ghc.haskell.org/trac/ghc/ticket/15982 The Cabal build script `build.cabal.bat` works reliably on my Windows machine, so I am proposing to switch to it by default, that is, to run it from the default `build.bat` script. The Stack build script can still be run directly if need be.
* Disable Shake Lint by default.Andrey Mokhov2019-01-165-8/+4
|
* Switch to the untracked version of getDirectoryFiles when scanning for GMP ↵Andrey Mokhov2019-01-162-6/+15
| | | | | | | | | objects See https://ghc.haskell.org/trac/ghc/ticket/15971. This is work in progress: this commit does the right thing, but does not yet fix the ticket.
* typoAlp Mestanogullari2019-01-161-1/+1
|
* crosslink hadrian/README.md and hadrian/doc/make.mdAlp Mestanogullari2019-01-162-2/+13
|
* Support printing `integer-simple` Integers in GHCiAlec Theriault2019-01-161-1/+3
| | | | | | | | | | This means that `:p` no longer leaks the implementation details of `Integer` with `integer-simple`. The `print037` test case should exercise all possible code paths for GHCi's code around printing `Integer`s (both in `integer-simple` and `integer-gmp`). `ghc` the package now also has a Cabal `integer-simple` flag (like the `integer-gmp` one).
* Hadrian: support extra libraries + OSX rpathAlec Theriault2019-01-165-24/+34
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes some of the issues that surfaced when trying to build dynamic GHC on OSX. Unfortunately, due some other `libffi` issues, this doesn't completely fix dynamic builds on OSX. - Use 'extra-libraries' from .cabal files instead of hardcoding which packages need which extra libs. Also add support for 'extra-lib-dirs'. - Make sure Hadrian looks in the right places to support both plain '<pkg>.buildinfo' and '<pkg>.buildinfo.in' files. - Make the '-rpath' support more robust across OS's (it previously didn't work on OSX and possibly windows either). Reviewers: angerman, alpmestan, adamse, DavidEichmann, bgamari, Phyx Subscribers: rwbarton, carter GHC Trac Issues: #15990 Differential Revision: https://phabricator.haskell.org/D5409
* Hadrian: configure packages with right 'htmldir'Alec Theriault2019-01-164-6/+21
| | | | | | | | | This means that we can query the package DB for haddock interfaces. Haddock uses this in its testsuite. 'cabal {v1-,v2,}-haddock' also uses this. Also thread through to Haddock package-specific overrides of GHC warnings.
* Document the Shake Lint feature.Andrey Mokhov2019-01-141-0/+5
|
* Clarify when to follow the instructions in doc/windows.md.Andrey Mokhov2019-01-141-4/+8
| | | | See https://gitlab.haskell.org/ghc/ghc/merge_requests/100#note_2349.
* Hadrian: Update README.mdAndrey Mokhov2019-01-141-90/+91
| | | | | | | * Update or remove a few outdated paragraphs * Use consistent naming (e.g. "Stage1" instead of occasionally "stage1") * Rewrite acknowledgements * Some more minor revisions
* Update `Cabal` submoduleHerbert Valerio Riedel2019-01-141-7/+9
| | | | | | | 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>
* Hadrian: Add support for building stage3Matthew Pickering2019-01-0919-101/+130
| | | | | | | | | | | | | | | | 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`.
* Hadrian: merge sections in profiling _p.a to .p_o for ghciZejun Wu2019-01-064-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "hadrian: Pass integer_backend to testsuite driver"Ben Gamari2018-12-241-2/+0
| | | | This reverts commit 442be690e1ca162e22d632df695c29f90625f33e.
* testsuite: Mark th tests as broken in ext-interp way in LLVM build flavoursBen Gamari2018-12-241-0/+4
| | | | | | | This is due to the failures documented in #16087. The condition here could be improved as it matches on `BUILD_FLAVOUR` instead of looking at the compiler flags. However, it's better than nothing and I hope we will be able to fix these issues before long.
* hadrian: introduce make-user-oriented docsAlp Mestanogullari2018-12-172-39/+217
| | | | | | | | | | | | | | | | | This commit introduces Hadrian docs specifically targeted at GHC devs who are used to building GHC with the make build system, adapting a good chunk of the following quickstart page we wrote over the last few months: https://ghc.haskell.org/trac/ghc/wiki/Building/Hadrian/QuickStart Reviewers: snowleopard, bgamari Reviewed By: snowleopard Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5446
* Hadrian: introduce userDefaultFlavour, making default flavour overridableAlp Mestanogullari2018-12-173-6/+28
| | | | | | | | | | | | | | | | | | | | | | | | This patch introduces the `userDefaultFlavour` user setting. It should be the name of the default flavour to use when no --flavour argument is passed. Before this patch, we would just always default to... the `default` flavour. With this patch, we default to whatever Flavour whose name is `userDefaultFlavour`, therefore providing a way for users to "persist" their choice of flavour, not having to repeat --flavour=[...] in every hadrian command. Test Plan: Set `userDefaultFlavour = "quickest"`, run `hadrian/build.sh`, check that the quickest flavour is indeed picked. Reviewers: snowleopard, bgamari Reviewed By: snowleopard Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15890 Differential Revision: https://phabricator.haskell.org/D5454
* hadrian: Pass integer_backend to testsuite driverBen Gamari2018-12-141-0/+2
|
* Support generating HIE filesAlec Theriault2018-12-111-3/+1
| | | | | | | | | | | | | | | | | | | | Adds a `-fenable-ide-info` flag which instructs GHC to generate `.hie` files (see the wiki page: https://ghc.haskell.org/trac/ghc/wiki/HIEFiles). This is a rebased version of Zubin Duggal's (@wz1000) GHC changes for his GSOC project, as posted here: https://gist.github.com/wz1000/5ed4ddd0d3e96d6bc75e095cef95363d. Test Plan: ./validate Reviewers: bgamari, gershomb, nomeata, alanz, sjakobi Reviewed By: alanz, sjakobi Subscribers: alanz, hvr, sjakobi, rwbarton, wz1000, carter Differential Revision: https://phabricator.haskell.org/D5239
* Hadrian: ability to run a subset of the testsuiteAlp Mestanogullari2018-12-114-15/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was supposed to be working already but didn't work when we specified several tests with --only. This patch not only fixes this but also makes it possible to specify a subset of tests to run with the TEST environment variable, like the make build system. Here are some examples: hadrian/build.sh test --only=plugins01 hadrian/build.sh test --only="plugins01 plugins02" TEST="plugins01 plugins02" hadrian/build.sh test TEST=plugins03 hadrian/build.sh test --only="plugins01 plugins02" When both the TEST environment variable and the --only flag are used, we simply concatenate the list of tests from both sources and ask the testsuite driver to run them all. This patch addresses #16026. Test Plan: hadrian/build.sh test --only="plugins01 plugins02" Reviewers: bgamari, snowleopard Reviewed By: bgamari, snowleopard Subscribers: rwbarton, carter GHC Trac Issues: #16026 Differential Revision: https://phabricator.haskell.org/D5431
* Hadrian: simple targets for building libraries and executablesAlp Mestanogullari2018-12-114-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert dynamically linking ghc.David Eichmann2018-12-113-12/+21
| | | | | | | | | | | | | | | | | | | | | | 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: 79d5427e1 and 89fa34ecd 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
* hadrian: Drop nix build scriptBen Gamari2018-12-082-124/+0
| | | | | It's currently too out-of-date to build current hadrian and is arguably completely broken anyways (see #15794).
* Hadrian: fix dynamicGhcPrograms value for the quickest flavourAlp Mestanogullari2018-12-071-1/+2
| | | | | | | | | | | | | | | | | | | | Quickest does not build anything in a dynamic way, so that flavour should default to not building "ghc programs" dynamically. I ran into this problem by building the 'docs' target with quickest, which failed because at some point we run a haddock command in a context whose Way is sensitive to dynamicGhcPrograms, and it started looking for dyn interface files when it shouldn't have. Test Plan: hadrian/build.sh --flavour=quickest docs Reviewers: snowleopard, bgamari Reviewed By: snowleopard Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5419
* hadrian: eliminate most of the remaining big rule enumerationsAlp Mestanogullari2018-12-076-104/+213
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* hadrian: optimise Rules.CompileAlp Mestanogullari2018-12-075-134/+349
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Hadrian: include 'findPtr' via find-ptr cabal flagAlec Theriault2018-12-042-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the latest in the 'findPtr' saga. See * 900c47f88784b91517c00be3e1087322e62f698e * 561748cb507505bd5b7bd76bdc57796d896b62a2 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
* Hadrian: Print all testsuite output to stdoutAndrey Mokhov2018-12-011-1/+4
| | | See https://ghc.haskell.org/trac/ghc/ticket/15951
* hadrian/test: Don't depend upon iserv on WindowsBen Gamari2018-12-011-1/+3
| | | | | Iserv is not supported on Windows. This fixes #15950 but this whole situation feels awfully fragile to me.
* Allow containers-0.6, QuickCheck-2.12 in HadrianRyan Scott2018-11-291-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: Currently, Hadrian has restrictive upper bounds on `containers` and `QuickCheck` that prevents it from building with the latest versions of each respective library (0.6.0.1 and 2.12.6.1). There doesn't appear to be any good reason to do so, since Hadrian builds fine with them, so let's bump the upper version bounds accordingly. Test Plan: ./build/hadrian.sh Reviewers: bgamari, alpmestan, snowleopard Reviewed By: snowleopard Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5389
* Hadrian: support dynamically linking ghcDavid Eichmann2018-11-293-9/+120
| | | | | | | | | | | | | | | | | | * (#15837 point 5) Use the -rpath gcc option and using the $ORIGIN variable which the dynamic linker sets to the location of the ghc binary. * (#15837 point 4) "-fPIC -dynamic" options are used when building ghc when either ghc or the rts have a dynamic way. * (#15837 point 7) "-shared -dynload deploy" options are only used when linking a library (no longer when linking a program). Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: adamse, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5281
View Lorry Controller Status