- Oct 05, 2019
-
-
They are only used in a file we construct directly, so just skip CPP.
-
The generated headers are now generated per stage, which means we can skip hacks like `ghc_boot_platform.h` and just have that be the stage 0 header as proper. In general, stages are to be embraced: freely generate everything in each stage but then just build what you depend on, and everything is symmetrical and efficient. Trying to avoid stages because bootstrapping is a mind bender just creates tons of bespoke mini-mind-benders that add up to something far crazier. Hadrian was pretty close to this "stage-major" approach already, and so was fairly easy to fix. Make needed more work, however: it did know about stages so at least there was a scaffold, but few packages except for the compiler cared, and the compiler used its own counting system. That said, make and Hadrian now work more similarly, which is good for the transition to Hadrian. The merits of embracing stage aside, the change may be worthy for easing that transition alone.
-
- Sep 07, 2019
-
-
- Sep 05, 2019
-
-
Some where using `True` / `False`, a legacy of when they were in `Config.hs`. See #16914 / d238d306 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.
-
- Aug 10, 2019
-
-
`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
-
- Aug 07, 2019
-
-
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
-
- Jul 24, 2019
-
-
Now that the target macros are not being used, we remove them. This prevents target hardcoding regressions.
-
- Jul 19, 2019
-
-
- 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.
-
- Jul 10, 2019
-
-
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.
-
- Jun 14, 2019
-
-
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 12, 2019
-
-
Ben Gamari authored
The linter now enforces our preference for `#if defined()` and `#if !defined()`.
-
- May 27, 2019
-
-
I jumbled some lines in e529c65e, 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.
-
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.
-
- May 21, 2019
-
-
- May 14, 2019
-
-
1. If GHC is to be multi-target, these cannot be baked in at compile time. 2. Compile-time flags have a higher maintenance than run-time flags. 3. The old way makes build system implementation (various bootstrapping details) with the thing being built. E.g. GHC doesn't need to care about which integer library *will* be used---this is purely a crutch so the build system doesn't need to pass flags later when using that library. 4. Experience with cross compilation in Nixpkgs has shown things work nicer when compiler's can *optionally* delegate the bootstrapping the package manager. The package manager knows the entire end-goal build plan, and thus can make top-down decisions on bootstrapping. GHC can just worry about GHC, not even core library like base and ghc-prim!
-
-
- May 08, 2019
-
-
- May 06, 2019
-
-
Get "Tables next to code" from the settings file instead.
-
- May 01, 2019
-
-
The bulk of the work was done in #712, making settings be make/Hadrian controlled. This commit then just moves the unlit command rules in make/Hadrian from the `Config.hs` generator to the `settings` generator in each build system. I think this is a good change because the crucial benefit is *settings* don't affect the build: ghc gets one baby step closer to being a regular cabal executable, and make/Hadrian just maintains settings as part of bootstrapping.
-
This allows it to eventually become stage-specific
-
- Apr 16, 2019
- Mar 06, 2019
-
-
The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
-
- Feb 20, 2019
-
-
This is a preparation for #16295: https://ghc.haskell.org/trac/ghc/ticket/16295 This commit mostly focuses on getting rid of untracked dependencies, which prevent Shake's new `--shared` feature from appropriately caching build rules. There are three different solutions to untracked dependencies: * Track them! This is the obvious and the best approach, but in some situations we cannot use it, for example, because a build rule creates files whose names are not known statically and hence cannot be specified as the rule's outputs. * Use Shake's `produces` to record outputs dynamically, within the rule. * Use Shake's `historyDisable` to disable caching for a particular build rule. We currently use this approach only for `ghc-pkg` which mutates the package database and the file `package.cache`. These two tickets are fixed as the result: Ticket #16271: https://ghc.haskell.org/trac/ghc/ticket/16271 Ticket #16272: https://ghc.haskell.org/trac/ghc/ticket/16272 (this one is fixed only partially: we correctly record the dependency, but we still copy files into the RTS build tree).
-
- Jan 16, 2019
-
-
...and does so in the lib folder of the right stage
-
- Jan 09, 2019
-
-
Matthew Pickering authoredThis 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`.
-
- Nov 22, 2018
-
-
* 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
-
- Dec 08, 2017
-
-
Ben Gamari authored
Sadly subtrees haven't worked quite as well as we would have liked for developers. See Hadrian #440.
-
