John Ericson authored 5 years ago and Marge Bot committed 5 years ago

They are only used in a file we construct directly, so just skip CPP.

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

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.

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

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.

Joachim Breitner authored 6 years ago and Marge Bot committed 5 years ago

`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

Jess authored 5 years ago and Marge Bot committed 5 years ago

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

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

Now that the target macros are not being used, we remove them. This
prevents target hardcoding regressions.

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

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.

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

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.

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

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.

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

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.

The linter now enforces our preference for `#if defined()` and
`#if !defined()`.

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

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.

Alp Mestanogullari authored 5 years ago and Marge Bot committed 5 years ago

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.

davide authored 5 years ago and Marge Bot committed 5 years ago

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

John Ericson authored 5 years ago and Ben Gamari committed 5 years ago

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!

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

Get "Tables next to code" from the settings file instead.

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

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.

John Ericson authored 5 years ago and Marge Bot committed 5 years ago

This allows it to eventually become stage-specific

Andrey Mokhov authored 5 years ago and Marge Bot committed 5 years ago

This is a temporary workaround for #16534. We generate wrapper scripts
<build-root>/ghc-stage1 and <build-root>/ghc-stage2 that can be used to
run Stage1 and Stage2 GHCs with the right arguments.

See #16534.

Ben Gamari authored 6 years ago and Marge Bot committed 6 years ago

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

Andrey Mokhov authored 6 years ago and Marge Bot committed 6 years ago

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

Alec Theriault authored 6 years ago and Ben Gamari committed 6 years ago

...and does so in the lib folder of the right stage

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

Alec Theriault authored 6 years ago and Ben Gamari committed 6 years ago

* 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

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