| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Now since this is generated by the build system we should ensure that it
is properly cleaned.
[skip ci]
|
|
|
|
|
| |
This fixes a few vestigial references to `settings` left over from !655.
Fixes #16715.
|
|
|
|
| |
This allows it to eventually become stage-specific
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 doesn't appear to be used anywhere in the build system and it
relies on perl. Drop it.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
`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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This means that `:p` no longer leaks the implementation details of
`Integer` with `integer-simple`. The `print037` test case should
exercise all possible code paths for GHCi's code around printing
`Integer`s (both in `integer-simple` and `integer-gmp`).
`ghc` the package now also has a Cabal `integer-simple` flag (like the
`integer-gmp` one).
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
https://phabricator.haskell.org/D5169 built libghci for both vanilla way
and profiling way. We need to include both in the bindist list so they
will be installed.
Test Plan:
```
$ grep '^BuildFlavour' mk/build.mk
BuildFlavour=perf
$ make test_bindist
$ grep HSghc-prim bindist-list.uniq
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.o
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3.a
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3-ghc8.7.20190101.so
ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3_p.a
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* All the tests in tests/ghci.debugger now pass with
-fexternal-interpreter. These tests are now run with the ghci-ext way
in addition to the normal way so we won't break it in the future.
* I removed all the unsafeCoerce# calls from RtClosureInspect. Yay!
The main changes are:
* New messages: GetClosure and Seq. GetClosure is a remote interface to
GHC.Exts.Heap.getClosureData, which required Binary instances for
various datatypes. Fortunately this wasn't too painful thanks to
DeriveGeneric.
* No cheating by unsafeCoercing values when printing them. Now we have
to turn the Closure representation back into the native representation
when printing Int, Float, Double, Integer and Char. Of these, Integer
was the most painful - we now have a dependency on integer-gmp due to
needing access to the representation.
* Fixed a bug in rts/Heap.c - it was bogusly returning stack content as
pointers for an AP_STACK closure.
Test Plan:
* `cd testsuite/tests/ghci.debugger && make`
* validate
Reviewers: bgamari, patrickdoc, nomeata, angerman, hvr, erikd, goldfire
Subscribers: alpmestan, snowleopard, rwbarton, thomie, carter
GHC Trac Issues: #13184
Differential Revision: https://phabricator.haskell.org/D4955
|
|
|
|
|
| |
I believe this was originally introduced to help test DPH, which is now
gone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done for consistency. We usually call the package file the same name the
folder has. The move into `utils` is done so that we can move the library into
`libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
`iserv.cabal` apart. This will make building the cross compiler with TH
simpler, because we can build the library and proxy as separate packages.
Test Plan: ./validate
Reviewers: bgamari, goldfire, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4436
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Poor DPH and its vectoriser have long been languishing; sadly it seems there is
little chance that the effort will be rekindled. Every few years we discuss
what to do with this mass of code and at least once we have agreed that it
should be archived on a branch and removed from `master`. Here we do just that,
eliminating heaps of dead code in the process.
Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
`primitive` submodules.
Test Plan: Validate
Reviewers: simonpj, simonmar, hvr, goldfire, alanz
Reviewed By: simonmar
Subscribers: goldfire, rwbarton, thomie, mpickering, carter
Differential Revision: https://phabricator.haskell.org/D4761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To resolve ticket #11295, I think it makes sense to stop hard-coding
the pass sequences used by GHC when compiling with LLVM into the
compiler
itself.
This patchset introduces a companion to the existing `llvm-targets` file
called `llvm-passes`. The passes file is a simple association list that
holds the default LLVM `opt` pass sequence used by GHC. This allows end
users to easily save their favorite optimization flags when compiling
with LLVM.
The main benefit for ticket #11295 is that when adding a custom pass
sequence, it tends to be an extremely long string that would be
unsightly in the code.
This is essentially part 1 of 2 for ticket #11295.
Test Plan: ./validate
Reviewers: bgamari, angerman
Reviewed By: angerman
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4695
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC.
The bits added are the C hooks into the RTS and a basic Haskell wrapper
to these C hooks. The main reason for these to be added to GHC proper
is that the code needs to be kept in sync with the closure types
defined by the RTS. It is expected that the version of HeapView shipped
with GHC will always work with that version of GHC and that extra
functionality can be layered on top with a library like ghc-heap-view
distributed via Hackage.
Test Plan: validate
Reviewers: simonmar, hvr, nomeata, austin, Phyx, bgamari, erikd
Reviewed By: bgamari
Subscribers: carter, patrickdoc, tmcgilchrist, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This shims out fopen and sopen so that they use modern APIs under the hood
along with namespaced paths.
This lifts the MAX_PATH restrictions from Haskell programs and makes the new
limit ~32k.
There are only some slight caveats that have been documented.
Some utilities have not been upgraded such as lndir, since all these things are
different cabal packages I have been forced to copy the source in different places
which is less than ideal. But it's the only way to keep sdist working.
Test Plan: ./validate
Reviewers: hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #10822
Differential Revision: https://phabricator.haskell.org/D4416
|
|
|
|
|
|
| |
See Phab:D4377 for the rationale. We will try this again.
This reverts commit 7c173b9043f7a9a5da46c5b0cc5fc3b38d1a7019.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done for consistency. We usually call the package file the same name the
folder has. The move into `utils` is done so that we can move the library into
`libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
`iserv.cabal` apart. This will make building the cross compiler with TH
simpler, because we can build the library and proxy as separate packages.
Reviewers: bgamari, simonmar, goldfire, erikd
Reviewed By: simonmar
Subscribers: tdammers, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4377
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Cabal library now commits `Lexer.hs` directly to the source tree,
so the build step where we'd call alex ourselves to generate that file
is no longer necessary, nor will it work.
See also: https://ghc.haskell.org/trac/ghc/ticket/14459
Reviewers: bgamari, hvr
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14459
Differential Revision: https://phabricator.haskell.org/D4240
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop the GHC.Prim madness with `virtual-module` support from cabal.
Needs https://github.com/haskell/cabal/pull/4875.
Bumps submodule libraries/Cabal to include the necessary logic for `virtual-module`.
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4179
|
|
|
|
|
|
|
|
| |
Unfortunately this (ironically) ended up breaking bindist testing since
we didn't have a package-data.mk. Unfortunately there is no easy way to
fix this.
This reverts commit 1e9f90af7311c33de0f7f5b7dba594725596d675.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are needed by the testsuite and consequently must be shipped in
the testsuite tarball to ensure that we can test binary distributions.
See #13897.
Test Plan: Validate
Reviewers: austin
Subscribers: snowleopard, rwbarton, thomie
GHC Trac Issues: #13897
Differential Revision: https://phabricator.haskell.org/D4039
|
|
|
|
|
|
|
|
|
|
| |
This effectively broke `make sdist`; the surprising thing is that
./validate didn't catch this (and thus the buildbots didn't either).
Also, I would have expected `EXTRA_PACKAGES` to be populated by the
data in `./packages` which already encodes that information...
This is a follow-up to 02ff70563e490d2a7f3141eab7229803c523da57
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a preparation for `haskeline` picking up a dependency on `stm`
real soon now. See https://github.com/judah/haskeline/pull/61 for details.
If we figure out a way to not bundle the libraries depended upon by the
GHCi executable in the global package database (see #8919 for the original
reason why we had to start bundling terminfo/haskeline in the first place)
we can get rid of `stm` again...
On the bright side, we were able to avoid uploading new `stm` releases for
over two years already, so it shouldn't cause too much trouble if GHC imposes
a strong preference on the `stm` package's version (this most likely will
mostly affect Linux distributions & similiar).
While at it, this also update the stm submodule to include relaxed
bounds to allow the upcoming base-4.11 version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LLVM backend shells out to LLVMs `opt` and `llc` tools. This clean
up introduces a shared data structure to carry the arguments we pass to
each tool so that corresponding flags are next to each other. It drops
the hard coded data layouts in favor of using `-mtriple` and have LLVM
infer them. Furthermore we add `clang` as a proper tool, so we don't
rely on assuming that `clang` is called `clang` on the `PATH` when using
`clang` as the assembler. Finally this diff also changes the type of
`optLevel` from `Int` to `Word`, as we do not have negative optimization
levels.
Reviewers: erikd, hvr, austin, rwbarton, bgamari, kavon
Reviewed By: kavon
Subscribers: michalt, Ericson2314, ryantrinkle, dfeuer, carter, simonpj,
kavon, simonmar, thomie, erikd, snowleopard
Differential Revision: https://phabricator.haskell.org/D3352
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This tool can be used to generate dll's for any list of object files
given to it. It will then repartition them automatically to fit within
a dll and generates as many dll's as needed to do this. Cyclic dependencies
between these generated dlls are handle automatically so there is no need
to tell it how to partition.
It is also a lot more general than `dll-split` as it is able to split any
package not just `libGHC`. It also uses a trick using GNU style import libraries
to hide the splitting from the rest of the pipeline. Which means come linking time
you don't need to know which dll contains what symbol or how many split dlls were
created.
The import libraries are by default created with libtool. However since libtool is BFD
based it is very slow. So if present and detected by configure the `genlib` tool
from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.
To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.
More detailed explaination of the process can be found here
https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force
GHC Trac Issues: #5987
Differential Revision: https://phabricator.haskell.org/D3883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes dll-split from the code base, the reason is dll-split
no longer makes any sense. It was designed to split a dll in two, but we
now already have many more symbols than would fit inside two dlls. So we
need a third one. This means there's no point in having to maintain this
list as it'll never work anyway and the solution isn't scalable.
Test Plan: ./validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, #ghc_windows_task_force
GHC Trac Issues: #5987
Differential Revision: https://phabricator.haskell.org/D3882
|
|
|
|
|
|
|
|
| |
Reviewers: austin, hvr
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bit me today: I was in validate mode without realising it and "make
clean" didn't help. I don't see a reason for this to be in distclean, as
it isn't generated by ./configure, which is the rule described in
https://ghc.haskell.org/trac/ghc/wiki/Building/Using
Test Plan: Is there a reason for this to be in distclean?
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cabal's parser has been rewritten in terms of Parsec (which is not
enabled yet in Cabal-2.0 by default, but can be enabled by a cabal
flag). The plan for Cabal is to drop support for the non-parsec parser,
so we need to prepare GHC to cope with new situation.
However, this means that lib:Cabal requires three new library
dependency submodules,
- parsec
- text
- mtl
What complicates matters is that we need to build `ghc-cabal` early on
during the bootstrap phase which currently needs to invoke `ghc --make`
directly. So these additional dependencies need to be integrated into
the monolithic `ghc --make` invocation which produces the `ghc-cabal`
executable.
Test Plan: `./validate --fast` passed
Reviewers: austin, bgamari
Subscribers: erikd, phadej, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several executables inexplicably appear twice in bindist.list, which
ends up producing multiple tar file entries, consequently breaking BSD
tar during extraction. I spent a fair amount of time trying to work out
where these duplicates were coming from to no avail. Since Hadrian is
right around the corner I'm satisfied with a terrible hack: just uniq
bindist.list before producing the bindist tarball.
Test Plan: Validate
Reviewers: austin
Subscribers: rwbarton, thomie
GHC Trac Issues: #13979, #13974
Differential Revision: https://phabricator.haskell.org/D3767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This copies the subset of Hoopl's functionality needed by GHC to
`cmm/Hoopl` and removes the dependency on the Hoopl package.
The main motivation for this change is the confusing/noisy interface
between GHC and Hoopl:
- Hoopl has `Label` which is GHC's `BlockId` but different than
GHC's `CLabel`
- Hoopl has `Unique` which is different than GHC's `Unique`
- Hoopl has `Unique{Map,Set}` which are different than GHC's
`Uniq{FM,Set}`
- GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is
needed just to filter the exposed functions (filter out some of the
Hoopl's and add the GHC ones)
With this change, we'll be able to simplify this significantly.
It'll also be much easier to do invasive changes (Hoopl is a public
package on Hackage with users that depend on the current behavior)
This should introduce no changes in functionality - it merely
copies the relevant code.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
Test Plan: ./validate
Reviewers: austin, bgamari, simonmar
Reviewed By: bgamari, simonmar
Subscribers: simonpj, kavon, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3616
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise this will fail if the prefix path contains spaces. Thanks to
marinelli for pointing this out.
Test Plan: Validate
Reviewers: austin
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When user installs _native_ build ghc executable is renamed
from '$(libexec)/bin/ghc-stage<N>' to '$(libexec)/bin/ghc'.
But not on windows!
In case of _cross-compiler_ rename should happen only
for '$(libexec)/bin/ghc-stage<N>' runnable on non-windows
platform.
Before the change '$(libexec)/bin/ghc-stage<N>' rename happened
for any compiler not targeting windows.
After the patch rename also happens for '$(libexec)/bin/ghc-stage1'
cross-compiler built for linux targeting windows (Stage1Only=YES case).
Or on a concrete example:
# host is x86_64-pc-linux-gnu
$ ./configure --target=i686-w64-mingw32
$ make install Stage1Only=YES
Before the change the layout was:
- '$(libexec)/bin/ghc-stage1' was installed
- bin/ghc contained 'exec $(libexec)/bin/ghc' # missing file!
After the change:
- '$(libexec)/bin/ghc' was installed
- bin/ghc contained 'exec $(libexec)/bin/ghc' # present file
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rebuild package.cache to ensure that it's newer than the package
database registration files, avoiding out-of-date cache warnings from
ghc-pkg. See #13375.
Test Plan: `make install`, run `ghc-pkg list`, look for out-of-date
cache warning
Reviewers: austin
Subscribers: rwbarton, thomie
GHC Trac Issues: #13375
Differential Revision: https://phabricator.haskell.org/D3569
|
|
|
|
|
| |
This is a follow-up to df6794035f1e4397d89896f329525e5368b7d1cc
which missed `INSTALL_BINS`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a derivation of a patch from @jophish.
This is necessary due to `haskeline`'s `terminfo` flag being marked as
`Manual` as of 43d7fa106027fcd4ec7f443923a8dd5b8c169f9c.
Reviewers: jophish, bgamari, austin
Reviewed By: bgamari
Subscribers: rwbarton, thomie, jophish
Differential Revision: https://phabricator.haskell.org/D3493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attempt to install cross-compiled mingw32 GHC built on linux failed as:
$ make install DESTDIR=$(pwd)/__i__
"mv" "$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc-stage2" \
"$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc"
mv: failed to stat
'$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc-stage2': \
No such file or directory
The rename should not be performed for windows targets.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change fixes case of installing cross-built GHC
from bindist (BINDIST=YES) on TARGET.
In this case we need to use TARGET tools in `INSTALLED_GHC{,_PKG}_REAL`.
The original change is provided by Fangrui Song
as pull request https://github.com/ghc/ghc/pull/34
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When cross-built GHC is being installed one of
latest steps is to register installed libraries
with 'ghc-pkg'.
GHC uses freshly installed 'ghc-pkg' and 'ghc-stage2'
for that.
Tested as:
./configure --target=aarch64-unknown-linux-gnu
make install DESTDIR=$(pwd)/__s2 STRIP_CMD=:
Before the change install failed on ghc-pkg execution phase:
".../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/bin/ghc-pkg" \
--force \
--global-package-db \
".../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/package.conf.d" \
update rts/dist/package.conf.install
/bin/sh: .../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/bin/ghc-pkg: \
No such file or directory
To avoid breakage we use 'ghc' and 'ghc-pkg' built by stage0.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: run 'make install' on stage2 crosscompiler
Reviewers: rwbarton, austin, bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3432
|
|
|
|
| |
This accidentally regressed in D3177.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a common thing that users who cross-compile must fight against.
It turns out that it's pretty straightforward to make is convenient.
Test Plan: Cross compile without a target `ncurses` available
Reviewers: danharaj, hvr, erikd, austin, rwbarton
Subscribers: rwbarton, thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build system uses the CrossCompiling variable to decide whether or
not we should build various packages that must be built using the
compiler. Consequently, it is important that we persist its value in
the binary distribution so we know during `make install` not to go
looking for files that would have been built for these packages. Failing
to do this causes #13325.
Test Plan: Cross compile, `make binary-dist`, and try installing the
binary distribution on the target
Reviewers: hvr, austin, trofi, rwbarton
Reviewed By: trofi, rwbarton
Subscribers: carter, trofi, rwbarton, erikd, thomie, snowleopard, davean
Differential Revision: https://phabricator.haskell.org/D3187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The plan is to release a separate library, 'compact', which gives a
friendly user-facing interface. This library is just enough so that we
can make sure the functionality is working in GHC.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: bgamari, dfeuer, austin, simonmar, hvr
Subscribers: thomie, erikd, snowleopard
Differential Revision: https://phabricator.haskell.org/D3206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.
This was originally added in https://phabricator.haskell.org/D2826
but that led to a compatibility issue with ghc 7.10.x on Windows.
That's fixed here and the revert reverted.
Reviewers: goldfire, hvr, austin, bgamari, Phyx
Reviewed By: Phyx
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2884
GHC Trac Issues: #13008
|
|
|
|
| |
This reverts commit 52ba9470a7e85d025dc84a6789aa809cdd68b566.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.
Reviewers: simonmar, goldfire, austin, hvr, bgamari
Reviewed By: simonmar
Subscribers: RyanGlScott, mpickering, angerman, thomie
Differential Revision: https://phabricator.haskell.org/D2826
|