summaryrefslogtreecommitdiff
path: root/ghc.mk
Commit message (Collapse)AuthorAgeFilesLines
* Fix doc build inconsistencyHarendra Kumar2016-08-251-0/+1
| | | | | | | | | | | | | | Remove the doc targets completely not partially when disabled. Otherwise even though we are able to build the targets but we will see some strange errors. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2470
* Compact RegionsGiovanni Campagna2016-07-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This brings in initial support for compact regions, as described in the ICFP 2015 paper "Efficient Communication and Collection with Compact Normal Forms" (Edward Z. Yang et.al.) and implemented by Giovanni Campagna. Some things may change before the 8.2 release, but I (Simon M.) wanted to get the main patch committed so that we can iterate. What documentation there is is in the Data.Compact module in the new compact package. We'll need to extend and polish the documentation before the release. Test Plan: validate (new test cases included) Reviewers: ezyang, simonmar, hvr, bgamari, austin Subscribers: vikraman, Yuras, RyanGlScott, qnikst, mboes, facundominguez, rrnewton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1264 GHC Trac Issues: #11493
* Move Extension type to ghc-boot-thBen Gamari2016-05-161-1/+2
| | | | | | | | | | | | | | | | | | | | This creates a new package, `ghc-boot-th`, to contain the `Extension` type, which now lives in `GHC.LanguageExtension.Type`. This ensures that the transitive dependency set of the `template-haskell` package remains minimal. The `GHC.LanguageExtensions.Type` module is also re-exported by `ghc-boot`, which provides an orphan `binary` instance as well. Test Plan: Validate Reviewers: goldfire, thomie, hvr, austin Reviewed By: thomie Subscribers: RyanGlScott, thomie, erikd, ezyang Differential Revision: https://phabricator.haskell.org/D2224
* Fix installation of static sphinx assetsBen Gamari2016-04-071-7/+1
| | | | | Previously the `_static` and `_sources` directories were installed in the wrong parents. See #11803
* Unset GREP_OPTIONS in build systemBen Gamari2016-02-091-1/+1
| | | | | | | | | | | | Test Plan: GREP_OPTIONS=--blah ./validate Reviewers: austin, thomie Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D1887 GHC Trac Issues: #11530
* Early error when crosscompiling + haddock/docsThomas Miedema2016-02-091-4/+19
| | | | | | | | | | | | | | | | | | | | When CrossCompiling=YES or Stage1Only=YES, building the haddocks and the User's Guide should be skipped, because haddock and mkUserGuidePart depend on the GHC API. See Note [No stage2 packages when CrossCompiling or Stage1Only] for details. There are several places in the build system where the variables HADDOCK_DOCS and BUILD_SPHINX_* are checked. Instead of also checking for the variables CrossCompiling or Stage1Only in all those places, `make` will now exit with a nice error message when the user requests the impossible. Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1882
* Enable RemoteGHCi on WindowsTamar Christina2016-01-271-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Makes the needed changes to make RemoteGHCi work on Windows. The approach passes OS Handles areound instead of the Posix Fd as on Linux. The reason is that I could not find any real documentation about the behaviour of Windows w.r.t inheritance and Posix FDs. The implementation with Fd did not seem to be able to find the Fd in the child process. Instead I'm using the much better documented approach of passing inheriting handles. This requires a small modification to the `process` library. https://github.com/haskell/process/pull/52 Test Plan: ./validate On Windows x86_64 Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr Reviewed By: simonmar Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1836 GHC Trac Issues: #11100
* Fixes to "make clean" for the iserv dirSimon Marlow2016-01-181-1/+1
|
* ghc.mk: Use Windows_Target instead of Windows_HostErik de Castro Lopo2016-01-101-2/+2
| | | | | | | | | | | | | | This is a step towards building a Linux to Windows cross-compiler. Test Plan: Build on Linux and Windows Reviewers: bgamari, hvr, austin, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1758 GHC Trac Issues: #10070
* Enable stack traces with ghci -fexternal-interpreter -profSimon Marlow2016-01-081-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main goal here is enable stack traces in GHCi. After this change, if you start GHCi like this: ghci -fexternal-interpreter -prof (which requires packages to be built for profiling, but not GHC itself) then the interpreter manages cost-centre stacks during execution and can produce a stack trace on request. Call locations are available for all interpreted code, and any compiled code that was built with the `-fprof-auto` familiy of flags. There are a couple of ways to get a stack trace: * `error`/`undefined` automatically get one attached * `Debug.Trace.traceStack` can be used anywhere, and prints the current stack Because the interpreter is running in a separate process, only the interpreted code is running in profiled mode and the compiler itself isn't slowed down by profiling. The GHCi debugger still doesn't work with -fexternal-interpreter, although this patch gets it a step closer. Most of the functionality of breakpoints is implemented, but the runtime value introspection is still not supported. Along the way I also did some refactoring and added type arguments to the various remote pointer types in `GHCi.RemotePtr`, so there's better type safety and documentation in the bridge code between GHC and ghc-iserv. Test Plan: validate Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1747 GHC Trac Issues: #11047, #11100
* Build system: delete ghc-pwdThomas Miedema2016-01-041-6/+0
| | | | | | | | | | | | | | | | On Windows, with msys2, `pwd` works (as can be seen by the use of `pwd` that slipped into the validate script), so there is really no need for `ghc-pwd` anymore. Test Plan: try it Reviewers: austin, bgamari, Phyx Reviewed By: Phyx Subscribers: Phyx, erikd Differential Revision: https://phabricator.haskell.org/D1731
* Synchronise ghci-package version with ghc-packageHerbert Valerio Riedel2015-12-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to simplify the task, the version munging logic has been radically simplified: Previously, in cases where the version contained dates as version components, the build-system would munge the version of the stage1 ghc package before registering the `ghc` package. However, this hack was already questionable at the time of its introduction (c.f. 7b45c46cbabe1288ea87bd9b94c57e010ed17e60). Simplifying the build-systems by avoiding such hacks may also help the shaking-up-ghc effort. So now we simply munge directly via the `.cabal` files, which gives a simpler picture, as now every stage is munged the same. Munging is only active when the first patch-level version component is a date. So stable snapshots and release candidates are unaffacted (as those have the date in the second patch-level version component) Reviewers: simonmar, bgamari, austin, thomie, ezyang Reviewed By: bgamari, thomie, ezyang Differential Revision: https://phabricator.haskell.org/D1673
* Build system: fix 'make sdist'Thomas Miedema2015-12-191-1/+1
| | | | | | This was broken in 4905b83a2d448c65ccced385343d4e8124548a3b. libraries/ghci/ghc.mk gets created by ./boot.
* Build system: allow bindist without docsThomas Miedema2015-12-171-1/+1
| | | | | | | | Useful for testing 'make binary-dist-prep' when HADDOCK_DOCS=NO. Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1648
* Build system: also put scripts in libexecdir/binThomas Miedema2015-12-171-11/+6
| | | | | | | | | This follows a similar change in 4905b83a2d448c65ccced385343d4e8124548a3b, where binaries are installed in libexecdir/bin instead of libexecdir. This fixes a problem with ghc not able to find ghc-split, when SplitObjs=YES.
* Fix libffi dependency, and remove redundant LibFFI.hscSimon Marlow2015-12-171-0/+6
| | | | | | | LibFFI.hsc was moved to libraries/ghci/GHCi/FFI.hsc, I just forgot to remove the old one. We also need an explicit dependency on libffi, which moves from compiler/ghc.mk to the top-level ghc.mk (because libraries/ghci/ghc.mk is auto-generated).
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (Apologies for the size of this patch, I couldn't make a smaller one that was validate-clean and also made sense independently) (Some of this code is derived from GHCJS.) This commit adds support for running interpreted code (for GHCi and TemplateHaskell) in a separate process. The functionality is experimental, so for now it is off by default and enabled by the flag -fexternal-interpreter. Reaosns we want this: * compiling Template Haskell code with -prof does not require building the code without -prof first * when GHC itself is profiled, it can interpret unprofiled code, and the same applies to dynamic linking. We would no longer need to force -dynamic-too with TemplateHaskell, and we can load ordinary objects into a dynamically-linked GHCi (and vice versa). * An unprofiled GHCi can load and run profiled code, which means it can use the stack-trace functionality provided by profiling without taking the performance hit on the compiler that profiling would entail. Amongst other things; see https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details. Notes on the implementation are in Note [Remote GHCi] in the new module compiler/ghci/GHCi.hs. It probably needs more documenting, feel free to suggest things I could elaborate on. Things that are not currently implemented for -fexternal-interpreter: * The GHCi debugger * :set prog, :set args in GHCi * `recover` in Template Haskell * Redirecting stdin/stdout for the external process These are all doable, I just wanted to get to a working validate-clean patch first. I also haven't done any benchmarking yet. I expect there to be slight hit to link times for byte code and some penalty due to having to serialize/deserialize TH syntax, but I don't expect it to be a serious problem. There's also lots of low-hanging fruit in the byte code generator/linker that we could exploit to speed things up. Test Plan: * validate * I've run parts of the test suite with EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th. There are a few failures due to the things not currently implemented (see above). Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1562
* Make ghc.mk compatible with pedantic /bin/sh implsHerbert Valerio Riedel2015-12-061-4/+6
| | | | | | | This fixes `for`-loops introduced via 64761ce9a899954a12d8e3ae8b400c5ad9648137 which can result in `for i in ;` which some `/bin/sh` implementations don't like.
* Build system: Add stage specific SRC_HC_(WARNING_)OPTSThomas Miedema2015-12-011-12/+5
| | | | | | | | | | | | | | | | | | * Add stage specific versions of SRC_HC_OPTS. These are currently only used for -Werror. The previous combination of GhcStage2HcOpts and GhcLibHcOpts didn't apply to utils/*. * Add stage specific versions of SRC_HC_WARNING_OPTS. These will later be used for new warning supression flags that should not be passed to the bootstrap compiler. * Move -Wall (and -Werror) related code back to mk/warnings.mk, where it was before 987d54274. Now all warning related code is nicely together. Include mk/warnings.mk after mk/custom-settings.mk to make this work. Reviewed By: bgamari, hvr Differential Revision: https://phabricator.haskell.org/D1536
* ghc.mk: Make install_docs rule sh-compatibleBen Gamari2015-11-161-6/+6
|
* Build system: use stage0 to build dll-splitThomas Miedema2015-11-081-1/+0
| | | | | | | | | | | | | | | | | When cross-compiling ghc itself, this prevents: "dll-split: cannot execute binary file: Exec format error" Test Plan: * ./configure --target=arm-linux-gnueabihf * DYNAMIC_GHC_PROGRAMS=YES * Stage1Only=NO Reviewers: rwbarton, bgamari, austin Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1430
* Build system: renable -Wall on validate (base)Thomas Miedema2015-11-031-0/+8
| | | | | | | | | | | | | | | | Problem: 'SRC_HC_OPTS += -Wall' in 'mk/warnings.mk' was getting overwritten by 'SRC_HC_OPTS = ...' in 'mk/flavours/*.mk'. It didn't affect the compiler or most other libraries, because most .cabal files define 'ghc-options: -Wall'. Bug introduced in commit 2c24fd707f8650205bb574ffac5f376239af3723, when moving validate settings from 'mk/validate-settings.mk' to 'mk/flavours/validate.mk'. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1425
* Apply WERROR only to stage2 HC optionsBen Gamari2015-11-011-1/+2
| | | | | | | | | | | | | Otherwise validate unnecessarily may fail during the stage1 build when booting with an older compiler. Test Plan: Try it Reviewers: thomie, austin Reviewed By: thomie, austin Differential Revision: https://phabricator.haskell.org/D1390
* Testsuite: suggest quoting $(TEST_HC)Thomas Miedema2015-10-301-2/+4
| | | | | | | | | | | | Test Plan: it works Reviewers: bgamari, rwbarton, austin Reviewed By: austin Subscribers: rwbarton Differential Revision: https://phabricator.haskell.org/D1377
* Revert "Build system: don't create mk/are-validating.mk"Thomas Miedema2015-10-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This reverts commit aecf4a5f96d0d3ffcf4cb2c67a20a610d7c64486. It turns out the Simons are relying on 'mk/are-validating.mk', see D1307. The workflow they are using is: * run ./validate * find a bug in the compiler * try to fix the bug, running 'make 1' (or 'make 2') repeatedly. Because of 'mk/are-validating.mk', this uses the same build settings as validate. * continue ./validate (--no-clean) I suggested two alternatives: A. run 'make 1 Validating=YES' instead of 'make 1' Problem: when running `./validate --fast` or `./validate --hpc` instead of a normal `./validate`, validate sets ValidateSpeed and ValdateHpc in mk/are-validating.mk. You would for example have to run 'make 1 Validating=YES ValidateSpeed=FAST' instead of 'make 1' to get the same build settings as `./validate --fast`, which is entirely too long and error prone. B. uncomment `#BuildFlavour=validate` in mk/build.mk, and include 'mk/validate.mk'. Problems: * any other settings you have in build.mk will also get used. * the distinction between 'mk/validate.mk' and 'mk/build.mk' becomes less clear. * it is easy to forget to include 'mk/validate.mk'. * the build system again doesn't have access to the ValidateSpeed and ValdateHpc settings set by validate. Neither of these two options is entirely satisfactory. Reviewers: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1383
* Provide a utility to check API AnnotationsAlan Zimmerman2015-10-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It is difficult for GHC developers to know if they have broken the API Annotations. This patch provides a utility that can be used as a test to show up errors in the API Annotations. It is based on the current tests for ghc-api/annotations which can parse a file using the just-built GHC API, and check that no annotations are disconnected from the ParsedSource in the output. In addition, it should be able to dump the annotations to a file, so a new feature developer can check that all changes to the parser do provide annotations. Trac ticket: #10917 Test Plan: ./validate Reviewers: hvr, thomie, austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1368 GHC Trac Issues: #10917
* Quote GHC_PKG in Makefile.Edward Z. Yang2015-10-221-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Make dataToQa aware of Data instances which use functions to implement toConstrRyanGlScott2015-10-131-4/+4
| | | | | | | | | | | | | | | | | | | | Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function freak out if using a `Data` instance that produces a `Constr` (by means of `toConstr`) using a function name instead of a data constructor name. While such `Data` instances are somewhat questionable, they are nevertheless present in popular libraries (e.g., `containers`), so we can at least make `dataToQa` aware of their existence. In order to properly distinguish strings which represent variables (as opposed to data constructors), it was necessary to move functionality from `Lexeme` (in `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named `bin-package-db`). Reviewed By: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1313 GHC Trac Issues: #10796
* Build system: don't create mk/are-validating.mkThomas Miedema2015-10-041-3/+0
| | | | | | | | | | A `make` build after running `./validate` earlier should use the normal mk/build.mk settings, without having to manually delete the leftover file mk/are-validating or run `make clean` first. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1307
* Build system: add mk/validate.mk.sampleThomas Miedema2015-10-031-1/+2
| | | | | | | | | | Reviewers: austin, bgamari Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D1303 modified: configure.ac
* Move user's guide to ReStructuredTextBen Gamari2015-10-031-22/+19
|
* Build system: check for inconsistent settings (#10157)Thomas Miedema2015-09-081-0/+39
| | | | | | | | | | | | | | | | | | | | | `configure` currently detects when the docbook and hscolour tools aren't available, and instead of failing outright (as it does for missing alex and happy), sets some variables in mk/config.mk to tell `make` not to build the documentation. Sometimes, however, you want to really make sure all documentation gets built, fully colourized. For example when making a release. To do so, you can override the mentioned variables from mk/config.mk in mk/build.mk (e.g. set HSCOLOUR_SRCS=YES). This patch adds some error checking to make sure that doing so will not result in weird build failures when those tools are still missing. Test Plan: ran `make` a couple of times, with different mk/config.mk settings. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1232
* Build system: cleanup BUILD_DIRS + add lots of NotesThomas Miedema2015-09-081-57/+117
| | | | | | | | | | | | | | | | | | | | | | | Summary: See Note [CrossCompiling vs Stage1Only] in mk/config.mk.in. See Note [Stage1Only vs stage=1] in mk/config.mk.in. See Note [No stage2 packages when CrossCompiling or Stage1Only]. Also: * use stage2 to build mkUserGuidePart, as was probably intended. Now the following represent the same set of packages: - packages that we build with ghc-stage2 - packages that depend on the ghc library Those packages are: haddock, mkUserGuidePart and ghctags. * don't let utils that don't depend on the ghc library depend on its package-data.mk file. Instead, let those utils directly depend on the package-data.mk files of the stage1 packages. Not sure if it improves anything, but I found it easier to explain what's going on this way. (partially) reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1218
* Build system: delete the InstallExtraPackages variableThomas Miedema2015-09-081-17/+4
| | | | | | | | | | | | | | Just install all packages that are built. Don't make an exception for the dph and extra packages. You can control whether the dph and extra packages should be build using the variables BUILD_DPH and BUILD_EXTRA_PKGS. These variables didn't exist before. But now that they do, InstallExtraPackages isn't really needed anymore. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1227
* Build system: implement `make install-strip` (#1851)Thomas Miedema2015-09-041-4/+17
| | | | | | Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1209
* Build system: simplify install.mk.inThomas Miedema2015-08-211-25/+25
| | | | | | | | | | This will allow fixing #1851 more easily ("make install-strip" should work). This reverts 57e2a81c589103b50da80a9e378b1a11285bd521: "On Cygwin, use a Cygwin-style path for /bin/install's destination" Update submodule haddock and hsc2hs.
* Build system: fail when encountering an unknown package tagThomas Miedema2015-07-181-1/+1
|
* Build system: do not build stm and parallel by defaultThomas Miedema2015-07-141-8/+6
| | | | | | | | | | | | | | | | | stm and parallel have an 'extra' tag in the ./packages file, so would get added to PACKAGES_STAGE2 by default, and subsequently build by the stage2 compiler. With this patch, this happens only when you set BUILD_EXTRA_PKGS=YES in build.mk. A normal validate still builds (and tests) the 'extra' packages, but they are skipped for `validate --fast`. Maybe this brings us closer to finishing within the 50 minute Travis limit as well. We can later try to give random, primitive and vector an 'extra' tag as well (now they have a 'dph' tag), but some tests will probably fail at first. Differential Revision: https://phabricator.haskell.org/D1065
* Build system: delete REGULAR_INSTALL_DYNLIBS and INSTALL_DYNLIBSThomas Miedema2015-07-131-14/+0
| | | | | | | | | | | | | | | | | Ever since we ship xhtml, terminfo and haskeline (#8919), commit 4caadb7cbee5c176abb99df25c4cc1657ae57f40, REGULAR_INSTALL_DYNLIBS is always empty. REGULAR_INSTALL_PACKAGES = PACKAGES_STAGE1 + compiler + PACKAGES_STAGE2 REGULAR_INSTALL_DYNLIBS = PACKAGES_STAGE1 + PACKAGES_STAGE2 - REGULAR_INSTALL_PACKAGES So we can delete it, and all the places where it is used. This simplifies ghc.mk a bit. Differential Revision: https://phabricator.haskell.org/D1062
* Build system: comments only [skip ci]Thomas Miedema2015-07-131-2/+13
|
* Build system: rename bindist to bindist-list...Thomas Miedema2015-07-021-1/+1
| | | | | ...to prevent accidental use of `make bindist`, when `make binary-dist` is called for.
* Rename $1_$2_$3_LIB_NAME to LIB_FILE.Edward Z. Yang2015-06-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we introduced user-friendly library names (e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to be written out by ghc-cabal, $1_$2_LIB_NAME. What I didn't realize at the time was that this conflicts with an existing variable in the build system, $1_$2_$3_LIB_NAME, which (confusingly) refers to something like 'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'. This is pretty confusing (despite never conflicting), so I renamed this variable to LIB_FILE for enhanced greppability. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1002
* Make GHC install libraries to e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh.Edward Z. Yang2015-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we'd install them to something like xhtml_0ACfOp3hebWD9jGWE4v4G which was fairly ugly; this commit changes the default install path to contain the full package name and version, as well as the package key. Needs a Cabal submodule update for the commit for install paths support "Add libname install-dirs variable, use it by default. Fixes #2437". It also contains some miscellaneous fixes for Cabal HEAD. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin Subscribers: bgamari, thomie Trac Issues: #10479 Differential Revision: https://phabricator.haskell.org/D922
* make sdist: distclean testsuite for real (#10406)Thomas Miedema2015-06-091-1/+1
|
* build: Clean testsuite before sdistAustin Seipp2015-06-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | When making the `sdist` tarball, we don't really need anything inside $(TOP)/testsuite in order to do our thing. So make sure we clean it first to avoid situations like #10406. With D917 landed, this can actually avoided entirely by fixing the official release process to instead build an `sdist` //first// from the clean git repository and then build that (to fixpoint) and test it. Then the originall clean tarball can be shipped. But it's nice to be safe in the general case where someone might want to (in the future) `sdist` out of their build tree. Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D956 GHC Trac Issues: #10406
* Build: ./boot && ./configure && make sdist (#8723)Thomas Miedema2015-06-041-24/+23
| | | | | | | | | | | | | | | | | Make it possible to run `make sdist` right after configure, without completing a complete build first. Test Plan: I compared the contents of the created `.tar.bz2` files in the `sdistprep` directory, after running `make sdist` both before and after completing a full build, using `diff -r`. There weren't any differences (after applying the patches from D914). Note that the `.tar.bz2` files were not exactly the same size, but they aren't either when tarring and bzipping the same directory twice. It seems tarring and bzipping is not deterministic (on my system). Differential Revision: https://phabricator.haskell.org/D917
* build: make haddock a bit less chattyAustin Seipp2015-06-021-1/+1
| | | | | | | | | | | | | | | | | | | Summary: Haddock outputs well over a thousand lines of file output just to give its executive summary about coverage. Kill this by default, since we really don't need it in any setting. Signed-off-by: Austin Seipp <austin@well-typed.com> Test Plan: Crossed my fingers. Reviewers: nomeata, thomie Reviewed By: thomie Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D933
* Build system: don't build runghc if GhcWithInterpreter=NO (#10261)Thomas Miedema2015-05-301-0/+4
| | | | | | | | | | | | | To test: * run `make clean` in utils/runghc * make sure inplace/bin doesn't contain runghc * set GhcWithInterpreter=NO in build.mk * run `make` * note that inplace/bin doesn't contain runghc It won't be installed either, nor will runhaskell. Differential Revision: https://phabricator.haskell.org/D920
* Build system: always use `make -r`Thomas Miedema2015-05-301-6/+0
| | | | | | | | | | | | | | | | | Do what this comment was suggesting: "Ideally we'd like to have 'make -r' turned on by default, because that disables all the implicit rules, but there doesn't seem to be a good way to do that." This change doesn't seem to have much effect on the time it takes to run make. Apparently clearing .SUFFIXES was enough for that. But it does make the output of `make -d` quite a bit shorter, which is nice. Note: ghc.mk is always called indirectly, so no need to set .SUFFIXES or MAKEFLAGS there again. Differential Revision: https://phabricator.haskell.org/D915
* Build system: always allow me to clean haddockThomas Miedema2015-05-301-0/+3
| | | | [skip ci]
View Lorry Controller Status