summaryrefslogtreecommitdiff
path: root/hadrian
Commit message (Collapse)AuthorAgeFilesLines
...
* Compiler should always get fingerprinting impl from baseJohn Ericson2019-09-131-1/+0
| | | | | 07ee15915d5a0d6d1aeee137541eec6e9c153e65 started the transition, but the job was never finished.
* Bump Cabal submodule to 3.1Sebastian Graf2019-09-121-1/+1
| | | | | | | | ------------------------- Metric Increase: haddock.Cabal T4029 -------------------------
* Bump Hadrian's QuickCheck dependencyLuke Lau2019-09-111-1/+1
|
* hadrian: fix _build/ghc-stage1 to make it callable from any directoryAlp Mestanogullari2019-09-071-2/+3
|
* Make sure all boolean settings entries use `YES` / `NO`John Ericson2019-09-052-8/+8
| | | | | | | | | Some where using `True` / `False`, a legacy of when they were in `Config.hs`. See #16914 / d238d3062a9858 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.
* Use C99 Fixed width types to avoid hack in base's configureJohn Ericson2019-09-011-1/+2
| | | | Define MD5Context in terms of `uint*_t` and don't use `HsFFI.h`.
* Add documentation for Hadrian expressionsJames Foster2019-08-222-0/+334
| | | | | This commit adds documentation on Hadrian's 'Expr' type and references the documentation in hadrian/README.md
* Consolidate `TablesNextToCode` and `GhcUnreigsterised` in configure (#15548)Joachim Breitner2019-08-105-11/+10
| | | | | | | | | | | | | | | | | | | | `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
* Remove old/broken(?) .ghci scriptMatthew Pickering2019-08-061-11/+0
| | | | | | | | | 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.
* hadrian: Refactor file patterns for future Shake changes (fixes #17005)James Foster2019-08-0616-120/+120
| | | | | | | | | | | | | | | | | 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
* Hadrian: make settings, platformConstants, etc dependencies of lib:ghcAlp Mestanogullari2019-08-024-18/+19
| | | | | | | | | | | 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.
* hadrian: Drop a stale limitation tracking issueDale Wijnand2019-07-291-2/+0
| | | | | | | https://github.com/snowleopard/hadrian/issues/187 was superseded by https://github.com/snowleopard/hadrian/issues/669, which has also been closed. So, optimistically, dropping this as a limitation issue.
* hadrian: relink to the flavours doc in the ghc repoDale Wijnand2019-07-281-1/+1
|
* Make stage 1 GHC target independentJohn Ericson2019-07-241-20/+4
| | | | | Now that the target macros are not being used, we remove them. This prevents target hardcoding regressions.
* Hadrian: run the testsuite in Windows CI jobAlp Mestanogullari2019-07-232-9/+13
| | | | | | | | | | | | 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.
* hadrian: Remove RTS -Waggregate-return warningMatthew Pickering2019-07-201-1/+0
| | | This was removed from make in 077b92fa39839a8e83cd87398435424403cf6486
* Make generated ghc-stage<n> scripts executableSebastian Graf2019-07-191-3/+4
|
* Fix formatting of --info's "Debug on" fieldBen Gamari2019-07-181-3/+1
| | | | | | As noted in #16914, the value `True` was used instead of `YES` here, in contrast to the other boolean fields emitted by `--info`. This confused the testsuite driver and broke the `ghc_debugged` testsuite predicate.
* Make GHC-in-GHCi work on WindowsSebastian Graf2019-07-173-5/+11
| | | | | | | | 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.
* Sort out Hadrian colored output flags (fix #16397)Artem Pelenitsyn2019-07-164-38/+20
| | | | | | | | | | 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`.
* Remove LLVM_TARGET platform macrosJohn Ericson2019-07-141-2/+1
| | | | | Instead following @angerman's suggestion put them in the config file. Maybe we could re-key llvm-targets someday, but this is good for now.
* hadrian: Build debug rts with -O0 -g3 and disable rts strippingMatthew Pickering2019-07-142-1/+6
| | | | Fixes #16920
* Make HsInstances and DynFlags compile with -O0 for Stage0 to speed up ↵James Foster2019-07-131-3/+8
| | | | Hadrian builds (fixes #16936)
* Add shake 0.18.3 to extra depsShayne Fletcher2019-07-121-0/+1
|
* hadrian/doc: Add some discussion of compilation stagesBen Gamari2019-07-092-0/+1010
| | | | | This documents some of the lore surrounding the nature and naming of GHC's stage numbers.
* Hadrian: fix source-dist ruleAlp Mestanogullari2019-07-091-11/+53
| | | | | | | | | | | | | | | | | 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.
* Hadrian: implement key-value settings for builder optionsAlp Mestanogullari2019-07-0911-40/+688
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Deduplicate "unique subdir" code between GHC and CabalJohn Ericson2019-07-091-25/+42
| | | | | | 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.
* Remove most uses of TARGET platform macrosJohn Ericson2019-07-091-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Bump Shake and copy instead of hard link from cloud cacheDavid Eichmann2019-07-082-1/+11
| | | | | | | | | 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.
* Hadrian: disable cloud build cache for symlinks #16800David Eichmann2019-07-021-0/+4
| | | | | This is a temporary workaround shake not supporting symlinks when using cloud/cached builds.
* Fix Happy deps for Stack (#16825)Sylvain Henry2019-06-271-10/+5
|
* Bump containers submodule to v0.6.2.1Ben Gamari2019-06-251-1/+1
|
* Fix cyclic dependencies when using --configureAndrey Mokhov2019-06-2521-105/+77
| | | | | | | | | | | This resolves #16809 (https://gitlab.haskell.org/ghc/ghc/issues/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.
* hadrian: Compile UserSettings with -O0Ben Gamari2019-06-181-0/+3
| | | | | This guarantees that the interface file for `UserSettings` doesn't contain any unfoldings, ensuring that a change in it requires minimal rebuilds.
* Disable optimisation when building Cabal in development flavoursBen Gamari2019-06-152-3/+7
| | | | | | | | | | This updates the make and Hadrian build flavours targetting developers to disable optimisation when building the Cabal library. Cabal tends to tickle some very bad compiler performance cases (e.g. #16577) so disabling optimisation here makes a sizeable impact on overall build time. See #16817.
* Disable optimisation when building Cabal lib for stage0Ben Gamari2019-06-151-0/+6
| | | | | | | | This disables optimisation when building Cabal for Hadrian and stage0 `ghc-cabal`. Cabal is performance critical in neither case nor will any performance difference here be visible to the end-user. See #16817.
* Hadrian: remove superfluous dependencies in Rules.CompileAlp Mestanogullari2019-06-131-2/+0
| | | | | | | | 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.
* Maintain separate flags for C++ compiler invocationsBen Gamari2019-06-133-0/+4
| | | | | | | 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.
* Hadrian: Track RTS library symlink targetsDavid Eichmann2019-06-135-48/+53
| | | | | This requires creating RTS library symlinks when registering, outside of the rule for the registered library file.
* Fix uses of #ifdef/#ifndefBen Gamari2019-06-121-5/+5
| | | | | The linter now enforces our preference for `#if defined()` and `#if !defined()`.
* Bump Cabal submoduleBen Gamari2019-06-121-3/+17
| | | | | | | (cherry picked from commit ff438786613f07df9b2d43eaeac49b13815d849d) Metric Increase: haddock.Cabal
* testsuite/mk/boilerplate.mk: rename 'ghc-config-mk' to 'ghc_config_mk'Alp Mestanogullari2019-06-111-1/+1
| | | | | | | | | | | | | 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.
* Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETERAlp Mestanogullari2019-06-111-0/+6
| | | | | | | | | | | | | | | | | 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
* Refactor the rules for .hi and .o into a single rule using `&%>` #16764David Eichmann2019-06-101-71/+64
| | | | | | | | | 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.
* Hadrian: need CPP preprocessor dependencies #16660David Eichmann2019-06-091-0/+13
| | | | | | | Use the new -include-cpp-deps ghc option (#16521) when generating .dependencies files in hadrian. This is version gated as -include-cpp-deps is a relatively new option.
* hadrian: Properly partition options in sourceArgsMatthew Pickering2019-06-091-1/+4
| | | | | | | | | Previously if you build the `ghc` package then it would has the default opts and the library opts. This is different behaviour to make where the library opts are only reserved for things in the `libraries` subdirectory (I believe) Fixes #16716
* Hadrian: Delete target symlink in createFileLinkUntrackedBen Gamari2019-06-071-1/+4
| | | | | Previously createFileLinkUntracked would fail if the symlink already existed.
* Hadrian: profiling and debug enabled ways support -eventlog tooAlp Mestanogullari2019-06-041-1/+3
|
* Hadrian: fix OSX build failure and add an OSX/Hadrian CI jobAlp Mestanogullari2019-06-041-1/+1
| | | | | | | The OSX build failure introduced in 3aa71a22 was due to a change in the glob we use to collect libffi shared libraries in hadrian/src/Rules/Libffi.hs. This commit fixes the problem and adds an OSX CI job that builds GHC with Hadrian, to make sure we don't break it again.
View Lorry Controller Status