summaryrefslogtreecommitdiff
path: root/rules
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove ghc-7.8 `-package-name`-compat handlingHerbert Valerio Riedel2015-12-311-13/+1
| | | | | | This code was introduced in 66218d15b7c27a4a38992003bd761f60bae84b1f to use `-package-name` for GHC 7.8, whereas GHC 7.10 needs the new `-this-package-key` flag.
* Synchronise ghci-package version with ghc-packageHerbert Valerio Riedel2015-12-282-2/+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: also put scripts in libexecdir/binThomas Miedema2015-12-171-3/+3
| | | | | | | | | 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.
* rules/haddock: Add EXTRA_HADDOCK_OPTS flagBen Gamari2015-12-171-1/+2
| | | | | | | | | | | | | | | Allowing one to pass the new `--hyperlinked-source` option to generate pretty marked-up sources for the core libraries. Test Plan: Try it Reviewers: hvr, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1643
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-172-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't pass CC= explicitly to `./configure` scriptsHerbert Valerio Riedel2015-12-141-1/+0
| | | | | | | | | | | | | | | | | | | This is a follow-up to fcc6b1d / D1608 which is made possible by the recent Cabal update: As `ghc-cabal` is called with `--with-gcc`, this gets passed to `./configure` as `CC=...` argument. So we don't need to set `CC=...` ourselves explicitly again. Prior to the changes in Cabal (pulled in via 0bf0cf936c7) and fcc6b1d, `./configure` scripts would be called with a `--with-cc` argument followed by a `--with-gcc` argument. After this commit, `./configure` will be passed a single `CC=...` argument constructed by the `Cabal` library. Reviewed By: erikd Differential Revision: https://phabricator.haskell.org/D1611
* Use idiomatic way to tell Autoconf the c compilerHerbert Valerio Riedel2015-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | The non-idiomatic `--with-cc` flag was added via 5c789e424c1461c1dadfd38c44fcb9e8f38bf755 However, `--with-cc` seems rather fragile and support for `--with-cc` needs to be added explicitly to autoconf-based Cabal packages. The `CC=` flag, however, is supported natively by GNU Autoconf, so let's use the standard facility for that. Relatedly, Cabal prior to version 1.24 used a similiar flag `--with-gcc=...`, but starting with Cabal-1.24 this has been changed to use `CC=...` instead as well (see https://github.com/haskell/cabal/pull/2946) This also updates a few submodules removing the now obsolete `--with-cc` flag support. Reviewed By: trofi, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1608
* Build system: fix 'make install-strip' in bindistThomas Miedema2015-12-121-0/+2
| | | | | | | | | | | | | | | | The INSTALL_PROGRAM variable is set in mk/config.mk, so we have to include that file before using it. Running 'make install' before './configure' in a bindist will now also display a nice message. Reviewers: hvr, austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1604 GHC Trac Issues: #1851
* Build system: Add stage specific SRC_HC_(WARNING_)OPTSThomas Miedema2015-12-011-2/+19
| | | | | | | | | | | | | | | | | | * 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
* Fix Windows builds after D1242Tamar Christina2015-11-211-1/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: Only use the merge_sections.ld linker script if SplitSections is enabled. I thought I had a way to make the linker script actually work on Windows and produce object files instead of image files (by using the "INSERT AFTER" linker script command to get the default script's output format setting), but that fix caused ghci to crash with an illegal instruction on startup. Gave up and made a simpler fix of just disabling this for normal builds, as it's only really relevant with SplitSections enabled anyway. Reviewers: austin, thomie, bgamari Reviewed By: austin, thomie Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D1505 GHC Trac Issues: #8405
* haddock.mk: Use \{1,\} instead of \+Ben Gamari2015-11-161-4/+4
| | | | | | | | This works around Mac OS X's sed, which doesn't support \+. For the record, The regex implementation in Mac OS X 10.8 and later is based on a heavily modified subset of TRE, http://laurikari.net/tre/
* rules/haddock: Set __HADDOCK_VERSION__Ben Gamari2015-11-121-0/+7
| | | | | | | | | | | | Test Plan: Validate Reviewers: austin, thomie Reviewed By: thomie Subscribers: kgardas, thomie Differential Revision: https://phabricator.haskell.org/D1467
* Implement function-sections for Haskell code, #8405Simon Brenner2015-11-123-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a flag -split-sections that does similar things to -split-objs, but using sections in single object files instead of relying on the Satanic Splitter and other abominations. This is very similar to the GCC flags -ffunction-sections and -fdata-sections. The --gc-sections linker flag, which allows unused sections to actually be removed, is added to all link commands (if the linker supports it) so that space savings from having base compiled with sections can be realized. Supported both in LLVM and the native code-gen, in theory for all architectures, but really tested on x86 only. In the GHC build, a new SplitSections variable enables -split-sections for relevant parts of the build. Test Plan: validate with both settings of SplitSections Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari Reviewed By: simonmar, thomie, bgamari Subscribers: hsyl20, erikd, kgardas, thomie Differential Revision: https://phabricator.haskell.org/D1242 GHC Trac Issues: #8405
* Revert "Build system: don't add ALL_HC_OPTS when linking"Ben Gamari2015-10-293-4/+4
| | | | | | | This reverts commit 9fc2d777f53110040f48ab27643a16888fa377f5. This appears to cause interface file issues during rebuilds. Punting back to @thomie for further investigation.
* Build system: don't add ALL_HC_OPTS when linkingThomas Miedema2015-10-283-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current scheme in rules/distdir-way-opts.mk is something like this: GHC_LD_OPTS = MOST_HC_OPTS + ALL_LD_OPTS MOST_DIR_HC_OPTS = MOST_HC_OPTS + -odir,-hidir,-stubdir ALL_HC_OPTS = MOST_DIR_HC_OPTS + -hisuf,-osuf,-hcsuf,-split-objs,-dynamic-too Notice that both ALL_HC_OPTS and GHC_LD_OPTS include MOST_HC_OPTS, and currently both got added when linking. Adding MOST_HC_OPTS twice results in overly long and hard to decipher command lines (and build logs). This commit fixes that. Afaik, -odir,-hidir,-stubdir,-hisuf,-osuf,-hcsuf,-spit-objs,-dynamic-too are all not needed when linking, so this change should be safe to make. GHC_LD_OPTS is for linking, ALL_HC_OPTS is for compiling. ALL_HC_OPTS was added to the linking commands in 37a6a52facd1c3999ce4472c50b0030568be1e04, to make sure -no-user-package-conf would be in the options list. It still is after this change. Reviewers: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1379
* Build system: comments only [skip ci]Thomas Miedema2015-10-272-10/+11
|
* Build system: fix `make -j1` (#10973)Thomas Miedema2015-10-173-6/+13
| | | | | | | | | | | | | | | | | | | | There are multiple hacks all over the build system to account for the fact that the ghc package uses different build subdirectories (stage1/stage2) than the other packages (dist/dist-install). One such hack filtered on 'ghc%', with the intention of filtering the ghc package only. After renaming bin-package-db to ghc-boot (d2f9972a35ce05ceb8a78893e433ef1df06f73ef, Phab:D1313, #10796), ghc-boot also got caught in the hack, which broke the build when running without parallelism. This patch replaces the before mentioned hack by a different one, such that filtering on 'ghc%' is no longer necessary. See Note [inconsistent distdirs]. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1333
* Rename PACKAGE_KEY and LIB_NAME in build system.Edward Z. Yang2015-10-144-18/+18
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Make dataToQa aware of Data instances which use functions to implement toConstrRyanGlScott2015-10-131-3/+3
| | | | | | | | | | | | | | | | | | | | 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
* sphinx: Don't share doctrees between targetsBen Gamari2015-10-101-3/+6
| | | | | | Sphinx may trip over itself when multiple instances are run in parallel. Fixes #10950.
* Move user's guide to ReStructuredTextBen Gamari2015-10-032-86/+65
|
* Build system: implement `make install-strip` (#1851)Thomas Miedema2015-09-042-3/+6
| | | | | | Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1209
* Build system: simplify install.mk.inThomas Miedema2015-08-211-1/+1
| | | | | | | | | | 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: delete half-baked Cygwin supportThomas Miedema2015-08-201-17/+1
| | | | | | | | | | | | | | | | | | | We only support building GHC on mys2 nowadays, see https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. This (partially) reverts various commits from a few years ago, among which: * 5775d5142da227d65fb86994d363eb16841ee642 "Add OSTYPE build-system variable, and use it" * 3fb8c431824aa2f3bd979e35d1a283546fcfbe74 "Fix building libgmp on cygwin" * cdbb4720c424500adb57cbbef69721d0b039fa46 "Fix cmd invocation by libffi cuild system on Windows 7 cygwin" * e8121501ee3549a35e954726ccfd871ac9d51f83 "Fix dblatex and xml* tool detection on Windows" Reviewed by: austin, Phyx Differential Revision: https://phabricator.haskell.org/D1155
* Build system: delete two unused filesThomas Miedema2015-07-131-24/+0
| | | | | They were introduced in 6ae696a1d1f25bf52923a3dd1c3b4a08e2033bfd. We do cross-compilation differently now.
* Build system: comments only [skip ci]Thomas Miedema2015-07-132-3/+3
|
* Build system: rename bindist to bindist-list...Thomas Miedema2015-07-021-6/+6
| | | | | ...to prevent accidental use of `make bindist`, when `make binary-dist` is called for.
* Make $1 in $1_$2_$3_FOO actually be directory.Edward Z. Yang2015-06-233-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we used $1_$2_PACKAGE_KEY to parametrize $1. But the documentation says that $1 should be the directory... and we're now putting the libraries in $1_$2_LIB_NAME. So use /that/. This is just alpha-renaming, so as long as we're consistent, there's no material difference.) I also fixed a bug of a package ID calculation which I missed first time around, which was tickled by this change. BTW, this means DEP_KEYS and TRANSITIVE_DEP_KEYS are unused, so remove them from ghc-cabal. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1010
* Rename $1_$2_$3_LIB_NAME to LIB_FILE.Edward Z. Yang2015-06-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix #10551 by using LIB_NAMES.Edward Z. Yang2015-06-221-1/+1
| | | | | | | | | | | | | | | | | | Summary: (NB: this code is dead at the moment since Windows is not built dynamically.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: none Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1001 GHC Trac Issues: #10551
* Use -package-id to specify libraries on command line.Edward Z. Yang2015-06-221-4/+3
| | | | | | | | | | | | | | | | Summary: There's not really any good reason to use -package-key over -package-id, so use the latter as standard practice. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1000
* Make GHC install libraries to e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh.Edward Z. Yang2015-06-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix the build when SplitObjs=YESThomas Miedema2015-06-061-1/+1
| | | | | | | The default (perf) build, which sets SplitObjs=YES, was broken with commit 5dd02864a844bcf6fe0018755ff261affdef3fea. I accidently removed the wrong `endif`. This should fix it.
* Fix the sdist buildThomas Miedema2015-06-061-2/+80
| | | | | | | | | | | | | | | Since commit 824e34e30338b4b1de0ab5467ffd29da4c7c805a, building ghc from a source distribution doesn't work. The error is: make[3]: *** No rule to make target 'utils/genprimopcode/dist/build/Lexer.hs', needed by 'utils/genprimopcode/dist/build/Lexer.o'. Stop. This commit fixes that. See note [Implicit rule search algorithm]. Differential Revision: https://phabricator.haskell.org/D959
* Build: remove more unnecessary CLEANING/=YES checksThomas Miedema2015-06-042-6/+0
| | | | | | | | | | | | | All these checks that CLEANING/=YES are no longer needed, because nowadays $1_$2_PROGNAME is always set explicitly, and $1_$2_PROG isn't. They were once introduce to allow `make clean` before `./configure`. I checked, and it still works. Remove the checks to make the build system a tiny bit shorter, and to no longer wonder why they are there. Differential Revision: https://phabricator.haskell.org/D941
* Build: remove unnecessary CLEANING/=YES checkThomas Miedema2015-06-042-7/+0
| | | | | | | | | | | | | | | | | | | The comment "INPLACE_BIN might be empty if we're distcleaning" is no longer true, and the check that CLEANING isn't YES isn't necessary. It was introduced in cd12c32de77ac18a69ed1733a558095567ec5ba8, to "make repeated 'make distclean' not fail", and and later revised in 39253008705e3ca590afdfa1b87bfbb5a16da7e7. It was needed because INPLACE_BIN was defined in config.mk. Commit 6793a033e1ce41f77316675e8f7aa83196a9b211 however, two days later, introduced a better solution to this problem: "Move the fixed paths out of config.mk, so cleaning works without configuring" So here we remove the original comment and check. One less thing to worry about when trying to understand the build system. Differential Revision: https://phabricator.haskell.org/D940
* Build: ./boot && ./configure && make sdist (#8723)Thomas Miedema2015-06-041-0/+46
| | | | | | | | | | | | | | | | | 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 configure and ghc-pkg a bit less chattyThomas Miedema2015-06-041-0/+11
| | | | | | Only when V=0. Differential Revision: https://phabricator.haskell.org/D943
* build: make haddock a bit less chattyAustin Seipp2015-06-021-0/+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: also clean the inplace wrapperThomas Miedema2015-05-301-0/+2
| | | | | | | | | | | | | | | | | Running `make clean` inside `utils/runghc` now does: "rm" -rf utils/runghc/dist-install "rm" -rf inplace/bin/runghc "rm" -rf inplace/lib/bin/runghc Instead of just: "rm" -rf utils/runghc/dist-install "rm" -rf inplace/lib/bin/runghc I think this was just an oversight. [skip ci] Differential Revision: https://phabricator.haskell.org/D919
* Build system: don't use supposedly local variable inside macroThomas Miedema2015-05-301-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | There is no support for local variables inside `make` macros (defined using the `define` keyword), see [wiki:Building/Architecture/Idiom/Macros]. In this case `make show VALUE=INPLACE_WRAPPER` would print some bogus value ("inplace/bin/mkUserGuidePart" actually, from the last BUILD_DIRS entry in ghc.mk that calls shell-wrapper), and using that variable somewhere might be a bug. Test Plan: I checked the rules directory with the following crude regexp, and this seems the be the only real offender. grep -P '^[^ $#\t][^$]*[^+]=' rules/* What it is supposed to do (from right to left): * look for variable assignments * but not updates (+=) * where the variable name doesn't contain any dollar signs * and the line doesn't start with whitespace or a comment [skip ci] Differential Revision: https://phabricator.haskell.org/D918
* Build system: make clean in utils/ghc-pkg should not delete inplace/lib/binThomas Miedema2015-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure $1_$2_PROG always gets assigned a value, even when cleaning. The problem with not setting the variable becomes apparent when looking at the following two lines of code: ``` $1_$2_INPLACE = $$(INPLACE_LIB)/bin/$$($1_$2_PROG) $(call clean-target,$1,$2_inplace,$$($1_$2_INPLACE)) ``` So running `make clean` in for example `utils/ghc-pkg` deletes `inplace/lib/bin/` instead of `inplace/lib/bin/ghc-pkg`. The offending code was introduced in commit 2b85372ca18115bb1d6363256fcea6f54e415bed. There is one small implication. When cleaning before configure, the variable $1_$2_PROG will now be assigned a slightly wrong value, because exeext$3 isn't known yet. But I think that's ok, as no files have been build yet, so it will just try to delete a slighly different nonexistent file. [skip ci] Differential Revision: https://phabricator.haskell.org/D916
* Build system: whitespace and comments onlyThomas Miedema2015-05-302-6/+18
| | | | [skip ci]
* Build system: check $CLEANING instead of $MAKECMDGOALSThomas Miedema2015-05-302-4/+4
| | | | | | | To check if we're cleaning, always check the $CLEANING variable, instead of sometimes $CLEANING, sometimes $MAKECMDGOALS. [skip ci]
* Build system: don't install haddock .t files (#10410)Thomas Miedema2015-05-271-1/+1
| | | | | | | | | | | | When generating a haddock .t file for a library, don't save it in the `dist-install/doc` directory for that library, as then it gets copied to the installation directory during `make install` by `ghc-cabal copy`. Instead, save it a few directories up; putting it next to `haddock-prologue.txt` seemed appropriate. Test Plan: run `make` in `tests/perf/haddock`. Differential Revision: https://phabricator.haskell.org/D903
* Drop old integer-gmp-0.5 from GHC source treeHerbert Valerio Riedel2015-03-311-2/+0
| | | | | | | | | | | | | | | | | | This completes what c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a (#9281) started. `integer-gmp-1.0` was added as an additional `libraries/integer-gmp2` folder while retaining the ability to configure GHC w/ the old `integer-gmp-0.5` to have a way back, and or the ability to easily switch between old/new `integer-gmp` for benchmark/debugging purposes. This commit removes the old `libraries/integer-gmp` folder and moves `libraries/integer-gmp2` into its place, while removing any mentions of "gmp2" as well as the to support two different `integer-gmp` packages in GHC's source-tree. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D769
* Use the gold linker for linux/ARM and android/ARM targets.Erik de Castro Lopo2015-03-122-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #8976 and #9873 by making use of the Binutils ld.gold linker explicit whenever the target is linux/ARM or android/ARM. This does not affect iOS where Apple provides its own linker. In order to achieve this, we need to add `-fuse-ld=gold` to the SettingsCCompilerLinkFlags setting and set SettingsLdCommand to `ld.gold` (or `${target}-ld.gold` when cross-compiling). In addition, simplifying the use of `$(CONF_GCC_LINKER_OPTS_STAGEn)`. This patch was tested by ensuring that the following worked as expected: * Native builds on linux/x86_64 (nothing changed). * Native builds on linux/arm (and uses the gold linker). * Linux to linux/arm cross compiles (and uses the cross gold linker). Contributions by Ben Gamari, Joachim Breitner and Reid Barton. Reviewers: nomeata, bgamari, austin, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D715 GHC Trac Issues: #8976 #9873
* Update Cabal submodule to latest 1.22 snapshotEdward Z. Yang2015-03-111-3/+3
| | | | | | | | | | | | | | | This changes the library file name format NOTE: This patch originally updated to Cabal HEAD, but was reduced to update to Cabal 1.22 HEAD by hvr as this is needed in order to update the filepath submodule to version 1.4.0, and subsequently to be cherry-picked into the ghc-7.10 branch Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D707
* Make top-level "configure" accept and propagate ↵PHO2015-02-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | --with-curses-{includes,libraries} to libraries Summary: If curses is installed into some non-standard path, we currently have to say something like the following in mk/build.mk: libraries/terminfo_CONFIGURE_OPTS += \ --configure-option=--with-curses-includes=/somewhere/include \ --configure-option=--with-curses-libraries=/somewhere/lib This is because the top-level configure does not accept nor propagate --with-curses-{includes,libraries} to libraries while it does so for iconv, gmp and libffi. It would be nice if curses were handled in the same manner. Test Plan: Install curses into some non-standard path. Then run the top-level "configure" script with options "--with-curses-includes=/path/to/curses/include" and "--with-curses-libraries=/path/to/curses/lib". Reviewers: austin Reviewed By: austin Subscribers: thomie, PHO Differential Revision: https://phabricator.haskell.org/D665 GHC Trac Issues: #10096
* runghc: be explicit about ghc version (#9054)Thomas Miedema2015-02-182-8/+6
| | | | | | | | | | | | | | Summary: runghc-7.x should always call ghc-7.x Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D664 GHC Trac Issues: #9054
View Lorry Controller Status