summaryrefslogtreecommitdiff
path: root/hadrian
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Hadrian: always generate the libffi dynlibs manifest with globbingAlp Mestanogullari2019-05-301-13/+9
| | | | | | | | | | | | | | | Instead of trying to deduce which dynlibs are expected to be found (and then copied to the RTS's build dir) in libffi's build directory, with some OS specific logic, we now always just use `getDirectoryFilesIO` to look for those dynlibs and record their names in the manifest. The previous logic ended up causing problems on Windows, where we don't build dynlibs at all for now but the manifest file's logic didn't take that into account because it was only partially reproducing the criterions that determine whether or not we will be building shared libraries. This patch also re-enables the Hadrian/Windows CI job, which was failing to build GHC precisely because of libffi shared libraries and the aforementionned duplicated logic.
* Hadrian: Add note about Libffi's Indicating Inputs #16653David Eichmann2019-05-291-7/+30
| | | | [skip ci]
* testsuite: introduce 'static_stats' testsAlp Mestanogullari2019-05-295-4/+19
| | | | | | | | | | | | | | | | They are a particular type of perf tests. This patch introduces a 'stats_files_dir' configuration field in the testsuite driver where all haddock timing files (and possibly others in the future) are assumed to live. We also change both the Make and Hadrian build systems to pass respectively $(TOP)/testsuite/tests/perf/haddock/ and <build root>/stage1/haddock-timing-files/ as the value of that new configuration field, and to generate the timing files in those directories in the first place while generating documentation with haddock. This new test type can be seen as one dedicated to examining stats files that are generated while building a GHC distribution. This also lets us get rid of the 'extra_files' directives in the all.T entries for haddock.base, haddock.Cabal and haddock.compiler.
* hadrian: Fix generation of settingsJohn Ericson2019-05-271-2/+2
| | | | | | | | I jumbled some lines in e529c65eacf595006dd5358491d28c202d673732, messing up the leading underscores and rts ways settings. This broke at least stage1 linking on macOS, but probably loads of other things too. Should fix #16685 and #16658.
* Hadrian: Fix problem with unlit path in settings fileAlp Mestanogullari2019-05-271-1/+3
| | | | | | | | | | | | | | | e529c65e introduced a problem in the logic for generating the path to the unlit command in the settings file, and this patches fixes it. This fixes many tests, the simplest of which is: > _build/stage1/bin/ghc testsuite/tests/parser/should_fail/T8430.lhs which failed because of a wrong path for unlit, and now fails for the right reason, with the error message expected for this test. This addresses #16659.
* Hadrian: Add Mising Libffi Dependencies #16653David Eichmann2019-05-251-5/+23
| | | | | | | | Libffi is ultimately built from a single archive file (e.g. libffi-tarballs/libffi-3.99999+git20171002+77e130c.tar.gz). The file can be seen as the shallow dependency for the whole libffi build. Hence, in all libffi rules, the archive is `need`ed and the build directory is `trackAllow`ed.
* add an --hadrian mode to ./validateAlp Mestanogullari2019-05-234-153/+165
| | | | | | | | | | | | | | When the '--hadrian' flag is passed to the validate script, we use hadrian to build GHC, package it up in a binary distribution and later on run GHC's testsuite against the said bindist, which gets installed locally in the process. Along the way, this commit fixes a typo, an omission (build iserv binaries before producing the bindist archive) and moves the Makefile that enables 'make install' on those bindists from being a list of strings in the code to an actual file (it was becoming increasingly annoying to work with). Finally, the Settings.Builders.Ghc part of this patch is necessary for being able to use the installed binary distribution, in 'validate'.
* Hadrian: add --test-root-dirs, to only run specific directories of testsAlp Mestanogullari2019-05-223-4/+49
| | | | | | | | | We can specify several of those, by using the flag multiple times or just once but combining the directories with ':'. Along the way, this patch also fixes the testsuite-related --only flag, so that we can use it many times instead of being force to specify a space-separated list of test in a single --only flag.
* Update resolver for for happy 1.19.10Shayne Fletcher2019-05-211-1/+1
|
* Refactor Libffi and RTS rulesDavid Eichmann2019-05-2110-139/+256
| | | | | | | | | This removes a hack that copies libffi files to the rts build directory. This was done in a libffi rule, but now an rts rule correctly needs and copies the relevant files from the libffi build dir to the rts build dir. Issues: #16272 #16304
* Hadrian: 'need' source files for various docs in Rules.DocumentationAlp Mestanogullari2019-05-141-0/+6
| | | | | | | | | | | | Previously, changing one of the .rst files from the user guide would not cause the user guide to be rebuilt. This patch take a first stab at declaring the documentation source files that our documentation rules depend on, focusing on the .rst files only for now. We eventually might want to rebuild docs when we, say, change the haddock style file, but this level of tracking isn't really necessary for now. This fixes #16645.
View Lorry Controller Status