summaryrefslogtreecommitdiff
path: root/rules/build-package-data.mk
Commit message (Collapse)AuthorAgeFilesLines
* Remove dll-split.Tamar Christina2017-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* configure: Remove --with-curses-includes flagBen Gamari2017-07-031-4/+0
| | | | | | | | | | | terminfo no longer needs to be able to find the ncurses headers. See https://github.com/judah/terminfo/pull/22. Reviewers: austin, hvr Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3688
* Always build GHCi libsSimon Marlow2017-03-151-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the introduction of -split-sections, using GHCi with the RTS linker is really slow: ``` $ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter) GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. real 0m3.793s ``` (when we use `-fexternal-interpreter` it uses the RTS linker by default, you can make it use the system linker by adding `-dynamic`) Building the GHCi libs doesn't take much time or space in the GHC build, but makes things much quicker for people using the RTS linker: ``` $ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter) GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. real 0m0.285s ``` So I propose that we build and ship them unconditionally. Test Plan: validate, perf tests above Reviewers: bgamari, austin, niteria, erikd, Phyx Reviewed By: bgamari Subscribers: rwbarton, thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3298
* Pass -v0 to ghc-pkg to reduce noise in build ouputMatthew Pickering2017-02-071-1/+1
| | | | | | | | | | | | | | | | By default ghc-pkg is quite noisy as it can't find interface files. Test Plan: Look at the build log stderr and see if there are lots of "cannot find any of" errors. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3103
* Updates to handle new CabalEdward Z. Yang2016-06-301-1/+1
| | | | | | | | | | | | | | | | | | Specifically per-component macros and multiple libraries. Contains Cabal submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, bgamari Reviewed By: austin, bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D2059
* Remove now obsolete LD_STAGE0 hackHerbert Valerio Riedel2016-03-271-5/+0
| | | | | | | This was introduced in 109a1e53287f50103e8a5b592275940b6e3dbb53 but isn't needed anymore because by now we're bootstrapping with GHC versions which already provide "ld command" in `ghc --info` (that field was added in GHC 7.8)
* Synchronise ghci-package version with ghc-packageHerbert Valerio Riedel2015-12-281-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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: comments only [skip ci]Thomas Miedema2015-07-131-2/+2
|
* 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
* Use the gold linker for linux/ARM and android/ARM targets.Erik de Castro Lopo2015-03-121-1/+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
* 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
* Update Cabal submodule to tip of v1.20 branchHerbert Valerio Riedel2014-04-161-1/+0
| | | | | | | | | | | | | | | | | | | This corresponds to the RC of the soon-to-be Cabal 1.20 release One noteworthy change is the removal of the `--with-ranlib` flag requiring a small adaptation in the GHC build system. Moreover two new licences were added, MPL and BSD2. Due to https://github.com/haskell/cabal/issues/1622 Cabal-1.20 now allows to strip libraries as well, this doesn't work well with `ghc-cabal copy` being fed a `":"` strip-command argument which was simply ignored in the past. The current code tries to retain this semantics as backward compat. However, this needs more investigation as I'm not sure if/why the `test_bindist` step doesn't want the libraries to be stripped on installation. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Pass custom CC and LD opts to Cabal when configuring a packageSimon Marlow2014-03-271-3/+11
| | | | | Cabal compiles a program to check for the existence of foreign libraries, so it needs to know our custom options, if any.
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-2/+2
|
* Change the ranlib detectionIan Lynagh2013-07-031-1/+1
| | | | | | | | On Windows, the ranlib in the path may not be the right ranlib (it may be the 32bit ranlib when we are making a Win64 compiler, or vice-versa). Therefore we can't leave it up to libffi to detect the right ranlib, but need to tell it which ranlib to use. This means that we need to find ranlib even if we don't actually need it ourselves.
* Fix the GHC package DLL-splittingIan Lynagh2013-05-141-1/+1
| | | | | | | There's now an internal -dll-split flag, which we use to tell GHC how the GHC package is split into 2 separate DLLs. This is used by Packages.isDllName to determine whether a call is within the same DLL, or whether it is a call to another DLL.
* Simplify ghc-cabalIan Lynagh2013-05-141-1/+1
| | | | | | It now consistently takes directory and distDirectory as its first 2 arguments. Also, it only supports configuring 1 package at a time now (we weren't using the ability to configure more than one at once).
* Some build system refactoringIan Lynagh2013-04-201-1/+1
|
* By default, use the dynamic way for programs in the GHC treeIan Lynagh2013-03-151-1/+1
| | | | | In particular, this means that GHCi will use DLLs, rather than loading object files itself.
* Update CabalIan Lynagh2013-03-111-7/+6
|
* Use more of the automatically generated INPLACE variablesIan Lynagh2013-03-031-3/+3
|
* iOS patch no 2: remove obsolete CROSS_COMPILE variable; #7699Ian Lynagh2013-02-171-2/+2
| | | | From StephenBlackheath
* iOS patch no 1: Select operating system; from StephenBlackheathIan Lynagh2013-02-171-3/+1
|
* Build system tweak: Do the package checks at configure timeIan Lynagh2013-02-151-0/+8
| | | | | | | | This removes the '.PHONY' rule, so means that "make" in a built tree won't repeat the check. We also now check the .cabal files for the executables as well as the libraries.
* Tidy up cross-compilingSimon Marlow2013-01-171-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have two cases: 1. building a cross-compiler 2. compiling GHC to run on a foreign platform These two are done with almost the same setup: (1) is the stage 1 compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES. The only difference between (1) and (2) is that you if you set up the build for (1), then it stops before stage 2 and you can 'make install' to install stage 1. Unfortunately, (2) didn't work, and the build system code needed some tidying up. Change to the way the build is set up: Before ------ To build a cross-compiler: ./configure --target=<..> To compile a foreign GHC: ./configure --host=<..> --target=<..> Now --- To build a cross-compiler: ./configure --target=<..> And set "Stage1Only=YES" in mk/build.mk To compile a foreign GHC: ./configure --target=<..>
* When cross-compiling, pass --host to package configure scriptsSimon Marlow2013-01-161-0/+6
| | | | | | Otherwise the configure script for e.g. base doesn't know that we're cross-compiling, and fails trying to run an executable compiled by the C cross-compiler.
* Pass --with-ld=$(LD) to ghc-cabal when configuring packages (#6086)Simon Marlow2013-01-161-0/+1
|
* Fix installation of vanilla librariesIan Lynagh2012-10-251-1/+1
|
* Make it possible to build with only way dynIan Lynagh2012-10-241-0/+10
|
* Fix installing when dynlibs-by-defaultIan Lynagh2012-10-141-2/+3
|
* Build fixIan Lynagh2012-06-291-1/+1
|
* Build fixesIan Lynagh2012-06-291-2/+2
|
* Merge remote-tracking branch 'origin/master' into pretty-buildIavor S. Diatchki2012-04-271-1/+1
|\
| * Add SRC_[CH]C_WARNING_OPTSIan Lynagh2012-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | This allows you to say things like SRC_HC_WARNING_OPTS += -fno-warn-unsupported-calling-conventions in mk/validate.mk. Unfortunately, we can't just use SRC_HC_OPTS, as that gets put before the more specific options (e.g. ghc-options in a .cabal file), many of which include -Wall. So now we have: ghc $(SRC_HC_OPTS) ... options from .cabal etc ... $(SRC_HC_WARNING_OPTS)
* | A build-system tweak for more readable build output.Iavor S. Diatchki2012-04-271-1/+1
|/ | | | | | | | | | | This change reduces the (default) verbosity of the build system. This makes it easier to spot warnings in the output and, also, it makes it easier to estimate how far along are we in the build process by just glancing at the output. To get the traditional fully verbose output, set V=1, like this: make V=1
* Improve support for cross-compilationSimon Marlow2012-01-301-1/+1
| | | | Patchset from Stephen Blackheath <stephen.blackheath@ipwnstudios.com>
* Pass alex and happy locations to ghc-cabal; fixes #5579Ian Lynagh2012-01-281-0/+2
| | | | | | We only use --with-alex / --with-happy if we know where alex / happy are. In particular, we don't need them when building from a source tarball.
* By default, be lax about dependencies on GHCIan Lynagh2011-08-281-1/+1
| | | | | | | | | | | | There are a number of things which technically depend on GHC (e.g. if ghc changes then Haskell files may be compiled differently, or Cabal packages may be configured differently). However, in practice, having a real dependency on GHC is just a pain: We normally don't want to spend time recompiling other things while we're working on the compiler, and even if we did, GHC will normally decide compilation isn't needed anyway. So by default we use order-only dependencies on GHC, i.e. GHC must exist, but if it's newer than other targets then rebuilding is not necessary.
* Pass the right tool locations to Cabal when generating package.mk filesIan Lynagh2011-04-291-1/+6
|
* Fix "make 1" etc following the build system changesIan Lynagh2011-01-271-0/+2
| | | | | The logic is now in mk/compiler-ghc.mk rather than being duplicated in ghc/Makefile and compiler/Makefile.
* Keep separate linker flags, for when we want to link with gcc or ldIan Lynagh2011-01-241-1/+1
|
* Add build system profiling to build systemIan Lynagh2011-01-231-0/+2
|
* Simplify the build system, and remove 2 phasesIan Lynagh2011-01-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | From http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/PhaseOrdering Phase 0: Includes: package-data.mk files for things built by the bootstrapping compiler. Builds: the dependency files for hsc2hs and genprimopcode. We need to do this now, as hsc2hs needs to be buildable in phase 1's includes (so that we can make the hpc library's .hs source files, which in turn is necessary for making its dependency files), and genprimopcode needs to be buildable in phase 1's includes (so that we can make the primop-*.hs-incl files, which are sources for the stage1 compiler library, and thus necessary for making its dependency files). Phase 1: Includes: dependency files for things built by the bootstrapping compiler. Builds: package-data.mk files for everything else. Note that this requires configuring the packages, which means telling cabal which ghc to use, and thus the stage1 compiler gets built during this phase. Phase "": Includes: dependency files for everything else. Builds: Everything else.
* Build system improvementsIan Lynagh2011-01-151-1/+4
| | | | | | | | | We no longer use dummy-ghc; instead we don't configure most packages until the stage1 compiler is available. We also now use Cabal for building the ghc-bin package. There are a couple more sanity checks too.
* Whitespace tweakIan Lynagh2011-01-151-1/+1
|
* Remove dead code now that we require the bootstrapping compiler be >= 6.12Ian Lynagh2010-12-141-18/+0
|
* Make CPPFLAGS variables, as well as CFLAGS and LDFLAGSIan Lynagh2010-12-071-1/+2
| | | | | | | | | | | This fixes the "does unsetenv return void" test in the unix package on OS X, if I tell it to make 10.4-compatible binaries. The test uses CPPFLAGS but not CFLAGS, so it thought it returned int (as it was in 10.5-mode), but the C compiler (using CFLAGS, so in 10.4 mode) thought it returned void. I also added CONF_LD_OPTS_STAGE$3 to the list of things in LDFLAGS, which looks like an accidental ommission.
* Always enable the archive-loading codeIan Lynagh2010-11-271-1/+1
| | | | If the GHCi .o lib doesn't exist, load the .a instead
View Lorry Controller Status