- Jul 20, 2019
-
-
This was removed from make in 077b92fa
-
- Jul 19, 2019
-
-
-
Ben Gamari authored
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.
-
- Jul 17, 2019
-
-
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.
-
- Jul 16, 2019
-
-
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`.
-
- Jul 14, 2019
-
-
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.
-
Fixes #16920
-
- Jul 13, 2019
-
-
- Jul 12, 2019
-
-
- Jul 10, 2019
-
-
This documents some of the lore surrounding the nature and naming of GHC's stage numbers.
-
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. -
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 -
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.
-
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.
-
- Jul 08, 2019
-
-
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.
-
- Jul 02, 2019
-
-
- Jun 27, 2019
-
-
- Jun 26, 2019
-
-
- Jun 25, 2019
-
-
This resolves #16809 (#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.
-
- Jun 18, 2019
-
-
This guarantees that the interface file for `UserSettings` doesn't contain any unfoldings, ensuring that a change in it requires minimal rebuilds.
-
- Jun 16, 2019
-
-
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.
-
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.
-
- Jun 14, 2019
-
-
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.
-
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.
-
- Jun 13, 2019
-
-
- Jun 12, 2019
-
-
Ben Gamari authored
The linter now enforces our preference for `#if defined()` and `#if !defined()`.
-
Ben Gamari authored
(cherry picked from commit ff438786613f07df9b2d43eaeac49b13815d849d) Metric Increase: haddock.Cabal
-
- Jun 11, 2019
-
-
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.
-
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
-
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.
-
- Jun 09, 2019
-
-
-
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
-
- Jun 07, 2019
-
-
Previously createFileLinkUntracked would fail if the symlink already existed.
-
- Jun 04, 2019
-
-
-
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.
-
- May 30, 2019
-
-
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.
-
- May 29, 2019
-
-
-
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.
-
- May 27, 2019
-
-
-
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.
-
