| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
| | |
|
| |
|
|
|
| |
The version suffix needs to be the version of the stage 0 compiler
when building shared libraries with the stage 0 compiler.
|
| |
|
|
|
|
| |
The object splitter was the last major user of perl. There remain a few
uses in nofib but we can just rely on the system's perl for this since
it's not critical to the build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- introduce a -k/--keep-test-files flag to prevent cleanup
- add -dstg-lint to the options that are always passed to tests
- infer library ways from the compiler to be tested instead of getting them
from the flavour (like make)
- likewise for figuring out whether the compiler to be tested is "debugged"
- specify config.exeext
- correctly specify config.in_tree_compiler, instead of always passing True
- fix formatting of how we pass a few test options
- add (potential) extensions to check-* program names
- build check-* programs with the compiler to be tested
- set TEST_HC_OPTS_INTERACTIVE and PYTHON env vars when running tests
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #16187.
This patch fixes various path concatenation issues to allow functioning
builds with hadrian when the build root location is specified with an
absolute path.
Remarks:
- The path concatenation operator (-/-) now handles absolute second operands
appropriately. Its behavior should match that of POSIX (</>) in this
regard.
- The `getDirectoryFiles*` family of functions only searches for matches
under the directory tree rooted by its first argument; all of the
results are also relative to this root. If the first argument is the
empty string, the current working directory is used.
This patch passes the appropriate directory (almost always either `top`
or `root`), and subsequently attaches that directory prefix so that
the paths refer to the appropriate files.
- Windows `tar` does not like colons (':') in paths to archive files, it
tries to resolve them as remote paths. The `--force-local` option
remedies this, and is applied on windows builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 initial motivation for this is to have a chance to run the binary
distribution rules in our Windows CI without having to install
sphinx-build and xelatex there, while retaining the ability to
generate haddocks. I just ended up extending this idea a little bit so
as to have control over whether we build haddocks, (sphinx) HTML manuals,
(sphinx) PDF manuals and (sphinx) manpages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
linking ghc.
Test Plan:
Ensure build environment does NOT have a system libffi installed (you may want to use a nix environment).
Then `hadrian/build.sh -c --flavour=default`
Reviewers: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15837
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
| |
`parallel` is used in exactly one place in the GHC tree: the T2317 test.
It seems almost by accident that it is a submodule; libraries needed
only for tests should net be included as submodules (see `QuickCheck`,
`async`, `haskell98`, `regex-compat`, `utf8-string`, `vector` and more
for examples).
T2317 will now get run only when `parallel` is installed instead of
`parallel` being required for the testsuite to run.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since the `$(docdir)` can be picked independently from the `$(libdir)`,
we need to make sure that that the `haddock-html` and `haddock-interface`
fields in the package DB (which is in the `$(libdir)`) get updated to
point to the appropriate places in the `$(docdir)`.
NB: in the make system, `ghc-cabal` would cover this sort of thing by
re-running `configure` on installation, but here we get away with a
couple lines of `sed` and a call to `ghc-pkg recache`.
Fixes #16202.
|
| |
|
|
|
|
|
|
| |
In Alp's refactoring of `getProgramContexts` he removed a call to
`getProgramContext` which was where the logic for this used to be
implemented.
Fixes #16214
|
| |
|
|
| |
...and does so in the lib folder of the right stage
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #16105
* Require Haddock's resource as runtime dependencies of the Haddock
builder. This means we no longer have to `need` particular resources
in every other documentation rule.
* Do a _tracked_ copy of both the 'html' and 'latex' folder resource
folders.
* Move resources into `stage1/lib` (NB: the `haddock` binary goes in
`stage1/bin`). Besides now actually matching the Haddock script
wrapper generated by BinaryDist, this also prepares for Haddock
in relocatable build folder detecting its own resources.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
objects
See https://ghc.haskell.org/trac/ghc/ticket/15971.
This is work in progress: this commit does the right thing, but does not
yet fix the ticket.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes some of the issues that surfaced when trying to build
dynamic GHC on OSX. Unfortunately, due some other `libffi`
issues, this doesn't completely fix dynamic builds on OSX.
- Use 'extra-libraries' from .cabal files instead of hardcoding
which packages need which extra libs. Also add support for
'extra-lib-dirs'.
- Make sure Hadrian looks in the right places to support both
plain '<pkg>.buildinfo' and '<pkg>.buildinfo.in' files.
- Make the '-rpath' support more robust across OS's (it previously
didn't work on OSX and possibly windows either).
Reviewers: angerman, alpmestan, adamse, DavidEichmann, bgamari, Phyx
Subscribers: rwbarton, carter
GHC Trac Issues: #15990
Differential Revision: https://phabricator.haskell.org/D5409
|
| |
|
|
|
|
|
| |
This also requires adapting `ghc-pkg` to use the new Cabal parsing API
as the old ReadP-based one has finally been evicted for good.
Hadrian bit finished by: Ben Gamari <ben@smart-cactus.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is the hadrain version of {D5169}
* We build squashed .o and .p_o for ghci when `dynamicGhcPrograms` is
`False`
* We no longer build them for rts as ghci never loads it
we need https://github.com/haskell/cabal/pull/5592 for cabal to copy
the built `.p_o` file.
Test Plan:
```
$ grep dynamicGhc hadrian/UserSettings.hs
, dynamicGhcPrograms = return False
$ touch ...
$ hadrian/build.sh --flavour=user -j --digest-or
$ find _build/stage1/libraries/ -name 'HS*-*.*o' | wc
62 62 3664
```
```
$ grep -C3 dynamicGhc hadrian/UserSettings.hs
userFlavour :: Flavour
userFlavour = performanceFlavour
{ name = "user"
, dynamicGhcPrograms = return False
}
$ hadrian/build.sh -j --flavour=user test --verbose
Unexpected results from:
TEST="T3807 T9208 T9293 annth_make ghci057 haddock.Cabal haddock.base
haddock.compiler"
SUMMARY for test run started at Wed Dec 5 17:45:39 2018 PST
0:03:16 spent to go through
6708 total tests, which gave rise to
26015 test cases, of which
19290 were skipped
29 had missing libraries
6600 expected passes
88 expected failures
3 caused framework failures
0 caused framework warnings
1 unexpected passes
7 unexpected failures
0 unexpected stat failures
$ find _build -name 'HSbase*.*o'
_build/stage1/lib/x86_64-linux-ghc-8.7.20181204/base-4.12.0.0/HSbase-4.1
2.0.0.o
_build/stage1/lib/x86_64-linux-ghc-8.7.20181204/base-4.12.0.0/HSbase-4.1
2.0.0.p_o
_build/stage1/libraries/base/build/HSbase-4.12.0.0.o
_build/stage1/libraries/base/build/HSbase-4.12.0.0.p_o
```
Reviewers: bgamari, simonmar, snowleopard
Reviewed By: snowleopard
Subscribers: alpmestan, rwbarton, carter
GHC Trac Issues: #15779
Differential Revision: https://phabricator.haskell.org/D5270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building a dynamically linked ghc is broken do to incorrectly building
and installing libffi. This disables building a dynamically linked ghc
and ghc-iserv-dyn while keeping most of the code in the relevant
commits: 79d5427e1 and 89fa34ecd
Test Plan:
Ensure build environment does NOT have a system libffi installed (you
may want to use a nix environment).
Then `hadrian/build.sh -c --flavour=default`.
Reviewers: bgamari, alpmestan
Reviewed By: alpmestan
Subscribers: rwbarton, carter
GHC Trac Issues: #15837
Differential Revision: https://phabricator.haskell.org/D5430
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following what was done to Rules.Library some time ago and to
Rules.Compile recently (D5412), this patch moves more rules away from
the "enumerate a lot of contexts and generate one rule for each" style
and instead uses the "parse data from file path to recover context"
approach. In fact, the only rules left to convert seem to be the ones
from Rules.Generate.
This effectively decreases the pauses described in #15938 further as
well as the amount of allocations and GC that we do, unsurprisingly.
Nowhere as drastically as D5412, though.
Test Plan: perform full build and generate docs
Reviewers: snowleopard, bgamari
Reviewed By: snowleopard
Subscribers: rwbarton, carter
GHC Trac Issues: #15938
Differential Revision: https://phabricator.haskell.org/D5422
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, as reported in #15938, resuming a build "in the middle",
e.g when building _build/stage1/libraries/base/, hadrian would take up
to a whole minute to get started doing actual work, building code.
This was mostly due to a big enumeration that we do in Rules.hs, to
generate all the possible patterns for object files for 1) all ways, 2)
all packages and 3) all stages. Since rule enumeration is always
performed, whatever the target, we were always paying this cost, which
seemed to grow bigger the farther in the build we stopped and were
resuming from.
Instead, this patch borrows the approach that we took for Rules.Library
in https://github.com/snowleopard/hadrian/pull/571, which exposes all the
relevant object files under as few catch-all rules as possible (8 here),
and parses all the information we need out of the object's path.
The concrete effect of this patch that I have observed is to reduce the
45-60 seconds pause to <5 seconds. Along with the Shake performance
improvements that Neil mentions in #15938, most of the pause should
effectively disappear.
Reviewers: snowleopard, bgamari, goldfire
Reviewed By: snowleopard
Subscribers: rwbarton, carter
GHC Trac Issues: #15938
Differential Revision: https://phabricator.haskell.org/D5412
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the latest in the 'findPtr' saga. See
* 900c47f88784b91517c00be3e1087322e62f698e
* 561748cb507505bd5b7bd76bdc57796d896b62a2
for the previous attempts. The problem with re-using the 'debug'
cabal flag for the purpose of forcing inclusion of 'findPtr' occurs
when 'debug' is one of the RTS ways, but RTS is not being compiled
with '-DDEBUG':
* the 'debug' flag gets passed to cabal, signalling to build
'rts' with the debug flavour, but also forcing inclusion of
the 'findPtr'/'_findPtr' symbol
* since '-DDEBUG' isn't enabled, that symbol doesn't show up in
the libraries, so executable that depend on 'rts' (everything)
will end up always requiring 'findPtr'/'_findPtr' but 'rts' won'y
provide it!
The fix is simple: create a a new 'find-ptr' cabal-flag whose only
purpose is forcing '-Wl,-u,findPtr'/'-Wl,-u,_findPtr'. Then, enable that
flag when the RTS is being compiled with '-DDEBUG'
Test Plan: ./hadrian/build.sh -c # on mac
Reviewers: alpmestan, snowleopard, bgamari, erikd, simonmar, Phyx
Reviewed By: alpmestan, snowleopard, Phyx
Subscribers: Phyx, rwbarton, carter
GHC Trac Issues: #15956
Differential Revision: https://phabricator.haskell.org/D5404
|
| |
|
| |
See https://ghc.haskell.org/trac/ghc/ticket/15951
|
| |
|
|
|
| |
Iserv is not supported on Windows. This fixes #15950 but this whole situation
feels awfully fragile to me.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, Hadrian was building all the appropriate dynamic ways for
libHSrts
but they were not picked up and installed in the package database when
we register the rts library. Since we use Cabal for registering
packages and
the .cabal files of packages as sources of truth for configuring and
installing,
we ended up patching Cabal to add a new field,
'extra-dynamic-library-flavours',
to specify those extra flavours to install in .cabal files:
https://github.com/haskell/cabal/pull/5606
We now make use of this in rts.cabal.in to expose dynamic flavours
behind a
Cabal flag, which Hadrian will use whenever we are building a GHC
flavour that
requires dynamic libraries.
This is all part of a larger plan to build a dynamic stage 2 GHC by
default,
like with make, which in turn will fix a lot of test failures. See
Test Plan:
hadrian/build.sh _build/stage1/lib/package.conf.d/rts-1.0.conf
_build/stage1/lib/x86_64-.../ should contain many libHSrts-*.so
Reviewers: snowleopard, DavidEichmann, bgamari, erikd, simonmar
Reviewed By: snowleopard, DavidEichmann
Subscribers: rwbarton, carter
GHC Trac Issues: #15837
Differential Revision: https://phabricator.haskell.org/D5385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As outlined in #15925, hadrian bindists had not made a clear choice with
respect to relocatable GHCs and wrapper scripts. This commit implements
the policy described in the ticket. That is:
- the bindists ship {bin, lib} as they are, modulo the addition of
haddock from stage2/bin
- we now _always_ generate wrapper scripts for all the programs that
are in the bindist's bin/ directory
The idea being that anyone on Linux/Windows/OS X can just unpack
the binary distribution anywhere and start using bin/ghc, while the
installation process systematicaly generates wrapper scripts.
Test Plan: hadrian/build.sh binary-dist ; cd
_build/bindist/ghc-X.Y.Z-arch/; configure --prefix=/tmp/foo && make
install
Reviewers: snowleopard, bgamari, angerman
Reviewed By: snowleopard, bgamari, angerman
Subscribers: rwbarton, carter
GHC Trac Issues: #15925
Differential Revision: https://phabricator.haskell.org/D5371
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The path to the 'include' subdirectory of 'rts' includes a folder that
whose name is generated by Cabal and mentiones the architecture and OS.
For example:
_build/stage1/lib/x86_64-osx-ghc-8.7.20181120/rts-1.0/include
Hadrian needs to be aware that Cabal renders architectures and OSes in
a slightly different way than GHC. There is already symmetric logic in
Cabal (for working with GHC environment files, which follow GHC's naming
conventions).
Test Plan: ./hadrian/build.sh -c "binary-dist" # on mac
Reviewers: snowleopard, alpmestan, bgamari
Reviewed By: snowleopard
Subscribers: rwbarton, carter
GHC Trac Issues: #15922
Differential Revision: https://phabricator.haskell.org/D5361
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More generally, we so far assumed that the testsuite would be executed
with a flavour that's as comprehensive as perf in terms of available RTS
and library flavours (at least vanilla + dynamic + prof). This would
manifest itself concretely by needing 3 "ways" of the iserv program,
unconditionally.
We now only require the ways among vanilla, dynamic and prof that we
can find in our current Flavour's rtsWays.
Test Plan:
hadrian/build.sh --flavour={quick, quickest} test now goes through
(with a few failing tests, of course).
Reviewers: bgamari, tdammers
Reviewed By: tdammers
Subscribers: mpickering, RyanGlScott, rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5355
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
... in addition to ghc-iserv and ghc-iserv-prof, as it is required
to get 10+ tests to pass
Reviewers: bgamari, alpmestan
Reviewed By: alpmestan
Subscribers: alpmestan, rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5327
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As it is required for 10+ tests.
Hadrian didn't give us a chance to build a given executable in vanilla
and profiling, simultaneously, under two different names. This patch
implements support for this in general and applies it to
ghc-iserv[-prof].
Test Plan: scc001 fails without this patch, passes with it.
Reviewers: snowleopard, bgamari
Reviewed By: bgamari
Subscribers: simonpj, ndmitchell, simonmar, rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5255
|
| |
|
|
|
|
| |
git-subtree-dir: hadrian
git-subtree-mainline: 575b35f4cdc18045bccd42d341d6f25d95c0696c
git-subtree-split: 45f3bff7016a2a0cd9a5455a882ced984655e90b
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Link to Quick Start guide
* Update README.md (hadrian/578)
* Fix AppVeyor (hadrian/577)
* Fix CircleCI
* Generic library rules (hadrian/571)
* Fix lint error (hadrian/575)
* Fix missing libHSghc-8.5-0.a (hadrian/574)
* Fix the path to touchy (hadrian/572)
* Fix integer-gmp build (hadrian/568)
* Undo fs*.h workaround
* Fix copying of fs*.h files during RTS registration (hadrian/566)
* Fix Windows build, improve error reporting (hadrian/565)
* Fix Windows build (hadrian/563)
* Fix boot and configure on AppVeyor (hadrian/561)
* Preliminary bindist (hadrian/558, hadrian/555)
* Unregister stage0 package first if it needs to be
cloned (hadrian/552)
* Fix Circle CI (hadrian/553)
* Fix warnings (hadrian/547)
* Merge pull request hadrian/542 from Mistuke/fix-specific-file
* Use Cabal directly in place of ghc-cabal + make build root
configurable (hadrian/531)
* Add user-defined flavour example for turning off dynamic
linking (hadrian/535)
* Add clean routines for fs (hadrian/533)
* Add 'git' to nativeBuildInputs in shell.nix (hadrian/530)
* Add extra include paths when invoking ghc-cabal (hadrian/526)
* Merge pull request hadrian/528 from snowleopard/bump-cabal
* Merge pull request hadrian/521 from snowleopard/drop-chmod
* Change permission bits for build.cabal.sh,
fixes hadrian/517 (hadrian/520)
* Pin nixpkgs and all-cabal-hashes in shell.nix (hadrian/511)
* Add troubleshooting section
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Make shell.nix less broken (hadrian/510)
* Add --configure flag to the script
* Undo iserv changes (hadrian/507)
* Fix ghc-cabal: Parsec modules are now found in libraries/parsec/src (hadrian/506)
* Move a bunch of types into dedicated modules (hadrian/502)
* Add --quickjump to Haddock (hadrian/505)
* Add iserv library (hadrian/504)
* Merge pull request hadrian/503 from snowleopard/angerman-patch-1
* Merge pull request hadrian/500 from snowleopard/runtime-deps
* Fix Hadrian after Cabal changes (hadrian/498)
* Drop custom logic for Scav_thr and Evac_thr (hadrian/497)
* Fix Haddock (hadrian/496)
|
| | |
|
| |
|
|
|
| |
It will remain a submodule until we are ready to merge Hadrian into the
tree.
|
| |
|
|
|
| |
Sadly subtrees haven't worked quite as well as we would have liked for
developers. See Hadrian #440.
|
| | |
|
| |
|
|
| |
Merge commit 'c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5'
|
| |
|
