| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
cmd uses RawCommand which uses Windows semantics to find the executable
which sometimes seems to fail for unclear reasons.
If we invoke ghc via bash then bash will find the ghc executable and
the issue goes away.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if you change these ^ flavour parameters, rebuilding is not
triggered, since `programContext` doesn't set up a dependency on
those values.
Exposing these values via an oracle does set the dependency and
properly triggers a rebuild of binaries.
Several attempts to factor out these actions ended up in cyclic
dependency here or there. I'm not absolutely happy with this variant
either, but at least it works.
====
Issue repro:
In UserSettings.hs:
```
dbgDynamic = defaultFlavour { name = "dbg-dynamic"
, dynamicGhcPrograms = pure True,
... }
dbgStatic = defaultFlavour { name = "dbg-static"
, dynamicGhcPrograms = pure False
... }
```
Then in console:
```
$ hadrian/build.sh -j --flavour=dbg-dynamic
... does the build
$ hadrian/build.sh -j --flavour=dbg-static
... does nothing, considers binaries up to date
```
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since MR !1025 fixed the Windows build, allowing us to build a binary
distribution, we can now run the testsuite in that CI job.
This required fixing 'createFileLink': it should not try to create
symlinks on Windows (that requires admin priviledges, which Hadrian can't
assume). We now instead fall back to copying.
This patch also removes some duplicated logic for iserv in the test rules,
where we handle our dependency on the iserv binaries in a special way.
|
|
|
|
|
|
|
|
|
|
|
| |
This resolves #16809 (https://gitlab.haskell.org/ghc/ghc/issues/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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This required making the 'ghc-config-mk' variable overridable in
testsuite/mk/boilerplate.mk, and then making use of this in hadrian
to point to '<build root>/test/ghcconfig' instead, which is where we
always put the test config.
Previously, we would build ghc-config and run it against the
GHC to be tested, a second time, while we're running the tests, because some
include testsuite/mk/boilerplate.mk. This was causing unexpected output
failures.
|
|
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|