GitLab

Convert hadrian buildscripts to unsuffixed, dashed form

final cleanups

This commit adds documentation on Hadrian's 'Expr' type and
references the documentation in hadrian/README.md

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 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`.

This documents some of the lore surrounding the nature and naming of
GHC's stage numbers.

This moves all URL references to Trac Wiki to their corresponding
GitLab counterparts.

This substitution is classified as follows:

1. Automated substitution using sed with Ben's mapping rule [1]
    Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
    New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...

2. Manual substitution for URLs containing `#` index
    Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
    New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz

3. Manual substitution for strings starting with `Commentary`
    Old: Commentary/XxxYyy...
    New: commentary/xxx-yyy...

See also !539

[1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json

This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.

Running the `./hadrian/ghci` target will load the main compiler into
a ghci session. This is intended for fast development feedback, modules are only
typechecked so it isn't possible to run any functions in the repl.

You can also use this target with `ghcid`.

The first time this command is run hadrian will need to compile a few dependencies
which will take 1-2 minutes. Loading GHC into GHCi itself takes about 30 seconds.

Internally this works by calling a new hadrian target called `tool-args`.
This target prints out the package and include flags which are necessary
to load files into ghci. The same target is intended to be used by other
tooling which uses the GHC API in order to set up the correct GHC API
session. For example, using this target it is also possible to use HIE
when developing on GHC.

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

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.

See ghc/ghc!100 (comment 2349).

* Update or remove a few outdated paragraphs
* Use consistent naming (e.g. "Stage1" instead of occasionally "stage1")
* Rewrite acknowledgements
* Some more minor revisions

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`.

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

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

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

Sadly subtrees haven't worked quite as well as we would have liked for
developers. See Hadrian #440.