summaryrefslogtreecommitdiff
path: root/ghc/ghc.mk
Commit message (Collapse)AuthorAgeFilesLines
* Rename ghci flag into internal-interpreterSylvain Henry2020-09-161-2/+2
| | | | | "ghci" as a flag name was confusing because it really enables the internal-interpreter. Even the ghci library had a "ghci" flag...
* Build a threaded stage 1 if the bootstrapping GHC supports it.Travis Whitaker2020-05-291-1/+8
|
* Fix GhcThreaded settingBen Gamari2020-02-081-0/+6
| | | | | | | | | | | | | | This adopts a patch from NetBSD's packaging fixing the `GhcThreaded` option of the make build system. In addition we introduce a `ghcThreaded` option in hadrian's `Flavour` type. Also fix Hadrian's treatment of the `Use Threaded` entry in `settings`. Previously it would incorrectly claim `Use Threaded = True` if we were building the `threaded` runtime way. However, this is inconsistent with the `make` build system, which defines it to be whether the `ghc` executable is linked against the threaded runtime. Fixes #17692.
* Per stage headers, ghc_boot_platform.h -> stage 0 ghcplatform.hJohn Ericson2019-10-041-5/+0
| | | | | | | | | | | | | | | | | | The generated headers are now generated per stage, which means we can skip hacks like `ghc_boot_platform.h` and just have that be the stage 0 header as proper. In general, stages are to be embraced: freely generate everything in each stage but then just build what you depend on, and everything is symmetrical and efficient. Trying to avoid stages because bootstrapping is a mind bender just creates tons of bespoke mini-mind-benders that add up to something far crazier. Hadrian was pretty close to this "stage-major" approach already, and so was fairly easy to fix. Make needed more work, however: it did know about stages so at least there was a scaffold, but few packages except for the compiler cared, and the compiler used its own counting system. That said, make and Hadrian now work more similarly, which is good for the transition to Hadrian. The merits of embracing stage aside, the change may be worthy for easing that transition alone.
* make: Fix bindist installationBen Gamari2019-06-041-5/+2
| | | | | This fixes a few vestigial references to `settings` left over from !655. Fixes #16715.
* Generate settings by make/hadrian instead of configureJohn Ericson2019-04-301-0/+3
| | | | This allows it to eventually become stage-specific
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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
* Rip out object splittingBen Gamari2019-03-051-6/+0
| | | | | | | | | | | | | | | 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
* Extract hard-coded LLVM opt flags into a fileKavon Farvardin2018-05-301-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Clean up opt and llcMoritz Angermann2017-09-061-0/+5
| | | | | | | | | | | | | | | | | | | | | 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
* Remove GhcDynamic (in favor of DYNAMIC_GHC_PROGRAMS)Reid Barton2017-04-121-3/+2
| | | | | | | | | | | | | | | | | | | | | | | DYNAMIC_GHC_PROGRAMS and GhcDynamic both tried to control whether the ghc binary was built as a dynamic executable, with confusing results. In particular, setting GhcDynamic=NO has no effect on systems where DYNAMIC_GHC_PROGRAMS defaults to YES. DYNAMIC_GHC_PROGRAMS is more fully-featured (it ensures that the correct flavor of the libraries is built, for example) so let's keep it and remove GhcDynamic to reduce confusion. This effectively reverts commit 3c6190b0. Test Plan: tested locally; harbormaster Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3428
* Updates to handle new CabalEdward Z. Yang2016-06-301-0/+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
* Synchronise ghci-package version with ghc-packageHerbert Valerio Riedel2015-12-281-9/+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
* Build system: cleanup BUILD_DIRS + add lots of NotesThomas Miedema2015-09-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | 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
* Replace hooks by callbacks in RtsConfig (#8785)Simon Marlow2015-04-071-0/+4
| | | | | | | | | | | | Summary: Hooks rely on static linking semantics, and are broken by -Bsymbolic which we need when using dynamic linking. Test Plan: Built it Reviewers: austin, hvr, tibbe Differential Revision: https://phabricator.haskell.org/D8
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-2/+2
|
* Add a kludgy dependency to fix compiling modules that use annotationsIan Lynagh2013-03-171-0/+6
| | | | We now make the stage 2 compiler depend on GHC.Desugar.
* Automatically add the $(exeext) to program namesIan Lynagh2013-03-031-3/+3
| | | | | | | We now define _PROGNAME, and _PROG is automatically defined with $(exeext). This will shortly automatically use the right exeext depending on what stage it is being compiled with (exeext may be different for different stages when cross-compiling).
* Use the automatic variables for touchy tooIan Lynagh2013-03-031-3/+3
|
* Automatically define _INPLACE variables for perl programs tooIan Lynagh2013-03-031-3/+3
| | | | and use them for split
* Use unlit_INPLACE rather than UNLIT in the build systemIan Lynagh2013-03-031-1/+1
|
* Rename $(Windows) to $(Windows_Host)Ian Lynagh2013-03-011-2/+2
|
* Always quote arguments to removeFiles (fixes Windows install).Geoffrey Mainland2013-02-221-1/+1
| | | | | Thanks to Daniel Pratt <colorblinddad@gmail.com> for pointing out the failure and fix.
* Finish removing BootingFromHcIan Lynagh2013-02-171-5/+0
|
* Build system tweak: Do the package checks at configure timeIan Lynagh2013-02-151-0/+5
| | | | | | | | 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/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=<..>
* Change how dependency generation works; fixes #7381Ian Lynagh2012-11-021-1/+1
| | | | | | We now do the initial dependency generation for the vanilla way regardless of what way flags and hisuf/osuf flags are given. This makes it easier to generate the right dependency info in the end.
* Build the dynamic way by default on Linux/amd64Ian Lynagh2012-10-031-0/+3
| | | | | | | | | | | | | This required various build system changes to get the build to go through. In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs to find their libraries. In the future, we might change the inplace tree to be the same shape as an installed tree instead. However, this would mean changing the way we do installation, as currently we use cabal's installation methods to install the libraries, but that only works if the libraries are under libraries/foo/dist-install/build/..., rather than in inplace/lib/...
* Tweak the build system handling of shell wrappersIan Lynagh2012-09-271-1/+1
| | | | | | | Rather than having a separate foo_INSTALL_SHELL_WRAPPER variable, we just use foo_INSTALL && foo_SHELL_WRAPPER
* Add more modes to mkDerivedConstantsIan Lynagh2012-09-131-3/+10
| | | | We now generate a platformConstants file that we can read at runtime.
* make sure to remove the right link before calling 'ln -s' (could we use 'ln ↵Gabor Greif2012-08-301-2/+2
| | | | -sf'?)
* Fix building with devel snapshotsIan Lynagh2012-03-171-0/+9
|
* tyopsGabor Greif2012-02-271-1/+1
|
* Improve support for cross-compilationSimon Marlow2012-01-301-2/+6
| | | | Patchset from Stephen Blackheath <stephen.blackheath@ipwnstudios.com>
* Time handling overhaulSimon Marlow2011-11-251-2/+5
| | | | | | | | | | | | | | | | | | | | | Terminology cleanup: the type "Ticks" has been renamed "Time", which is an StgWord64 in units of TIME_RESOLUTION (currently nanoseconds). The terminology "tick" is now used consistently to mean the interval between timer signals. The ticker now always ticks in realtime (actually CLOCK_MONOTONIC if we have it). Before it used CPU time in the non-threaded RTS and realtime in the threaded RTS, but I've discovered that the CPU timer has terrible resolution (at least on Linux) and isn't much use for profiling. So now we always use realtime. This should also fix The default tick interval is now 10ms, except when profiling where we drop it to 1ms. This gives more accurate profiles without affecting runtime too much (<1%). Lots of cleanups - the resolution of Time is now in one place only (Rts.h) rather than having calculations that depend on the resolution scattered all over the RTS. I hope I found them all.
* Improve the way we call "rm" in the build system; fixes trac #4916Ian Lynagh2011-11-191-2/+2
| | | | | | | | | | We avoid calling "rm -rf" with no file arguments; this fixes cleaning on Solaris, where that fails. We also check for suspicious arguments: anything containing "..", starting "/", or containing a "*" (you need to call $(wildcard ...) yourself now if you really want globbing). This should make things a little safer.
* Remove an old "ToDo" commentIan Lynagh2011-09-131-1/+0
|
* sanitise naming of package listsSimon Marlow2011-08-051-1/+1
| | | | | | | | | | | | | | | The *predicates* all start with "PKGS_THAT_...", e.g.: PKGS_THAT_BUILD_WITH_STAGE0 (previously "PACKAGES_STAGE0") PKGS_THAT_BUILD_WITH_STAGE2 (previously "STAGE2_PACKAGES") PKGS_THAT_USE_TH (previously "TH_PACKAGES) etc. (there are a few more) the lists of packages to build are now consistently named: PACKAGES_STAGE0 PACKAGES_STAGE1 (previously just "PACKAGES") PACKAGES_STAGE2
* Follow Cabal reorganisation, and improve build system a littleIan Lynagh2011-06-231-0/+1
|
* Rename "extra-gcc-opts" to "settings", and start generalising itIan Lynagh2011-04-211-5/+5
|
* Make the compiler depend on unlit existingIan Lynagh2011-04-201-11/+13
| | | | | Fixes an unreg build failure. I've also now made these sorts of dependencies order-only.
* Remove dead code, now that -fvia-c is a no-opIan Lynagh2011-04-041-3/+3
|
* Fix ghci in stage3Ian Lynagh2011-01-231-5/+1
|
* Manually control more of the Cabal flags for the compiler and ghc packagesIan Lynagh2011-01-211-0/+8
| | | | | | For some reason the Windows HEAD builder has started thinking the ghci flag should be on in stage 1. This should fix it, and generally make things a little more resilient.
* Remove some hardcoded makefile settingsIan Lynagh2011-01-211-19/+0
| | | | | Now that we used cabal to configure the ghc-bin package they are no longer needed.
* Handle dependencies of programs on libraries correctlyIan Lynagh2011-01-161-5/+0
|
* Remove some flags that are redundant now GHC gets configured by CabalIan Lynagh2011-01-161-10/+0
|
* Change some HC_OPTS var handlingIan Lynagh2011-01-161-19/+21
| | | | In particular, this means ghc gets built with -rtsopt, -threaded, etc again.
* Remove some unnecessary workaroundsIan Lynagh2011-01-161-9/+0
| | | | | We can now rely on cross-package deps working properly, as we require GHC 6.12.
* Build system improvementsIan Lynagh2011-01-151-2/+2
| | | | | | | | | 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.
View Lorry Controller Status