summaryrefslogtreecommitdiff
path: root/ghc/ghc-bin.cabal.in
Commit message (Collapse)AuthorAgeFilesLines
* Add Cabal synopses and descriptionsBen Gamari2016-01-051-3/+4
| | | | | | | | | | | | | | | | Various people (myself included) have complained about the lack of useful descriptions for the various packages included in GHC's source tree. Fix this. Test Plan: Validate Reviewers: austin, thomie Reviewed By: thomie Subscribers: angerman, ezyang Differential Revision: https://phabricator.haskell.org/D1736
* Synchronise ghci-package version with ghc-packageHerbert Valerio Riedel2015-12-281-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rename GHCi's UI modules into GHCi.UI(.*)Herbert Valerio Riedel2015-12-211-4/+4
| | | | | | | | | | | | Further work refactoring and enhancing GHCi will make it desirable to split up GHCi's code-base into multiple modules with specific functions, and rather than have several top-level 'Ghci*' modules, it's nicer to have a common namespace. This commit is provides the basis for that. Note that the remaining GHCi.* namespace belongs to the new `ghci` package. Differential Revision: https://phabricator.haskell.org/D1593
* Minor clean-up to ghc-bin.cabal.inHerbert Valerio Riedel2015-12-211-7/+9
| | | | This has been factored out of D1673
* Merge new commands from ghci-ng (re #10874)Herbert Valerio Riedel2015-12-201-4/+17
| | | | | | | | | | | | | | | | | | | | | This adds the new commands `:all-types`, `:loc-at`, `:type-at`, and `:uses` designed for editor-integration (such as Emacs' `haskell-mode`). This was originally implemented by Chris Done on https://github.com/chrisdone/ghci-ng and has been in use by Emacs' `haskell-mode` for over a year already, and closely missed the GHC 7.10 release back then. I've squashed the commits, rebased to GHC HEAD, and heavily refactored and improved the patch. Tests will be added in a separate commit. Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1240
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Expose enabled language extensions to THBen Gamari2015-12-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This exposes `template-haskell` functions for querying the language extensions which are enabled when compiling a module, - an `isExtEnabled` function to check whether an extension is enabled - an `extsEnabled` function to obtain a full list of enabled extensions To avoid code duplication this adds a `GHC.LanguageExtensions` module to `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy consequence of this is that the ungainly `DynFlags` lost around 500 lines. Moreover, flags corresponding to language extensions are now clearly distinguished from other flags due to the `LangExt.*` prefix. Updates haddock submodule. This fixes #10820. Test Plan: validate Reviewers: austin, spinda, hvr, goldfire, alanz Reviewed By: goldfire Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1200 GHC Trac Issues: #10820
* Update process submodule to process-1.4 releaseHerbert Valerio Riedel2015-11-021-1/+1
| | | | | We already used a process-1.4 snapshot with non-bumped version, so this commit is mostly a `.cabal` file upper-bound relaxation change.
* Update process submoduleHerbert Valerio Riedel2015-11-011-1/+1
| | | | | | | | | | This is needed to prepare for #11026 as this update relaxes the upper bounds on `base` to allow for `base-4.9.0.0` This also needs to relax a few upper bounds on process in some cabal files (there will be another process submodule update soon, as a major version bump of process' version is still pending)
* Always force the exception in enqueued commandsZejun Wu2015-06-091-0/+1
| | | | | | | | | | | | | | `enqueueCommands` should always force exception in commands. Otherwise the exception thrown in `:cmd` (e.g. `:cmd return $ head []`) will cause GHCi to terminate with panic. Test Plan: `cd testsuite/tests/ghci/ && make` Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D967 GHC Trac Issues: #10501
* Update filepath submodule to filepath-1.4 snapshotHerbert Valerio Riedel2015-03-111-1/+1
| | | | | | This also needs to update a couple of other submodules to update the upper bound on filepath to allow this major version bump to 1.4.0.0
* Convert `ghc-bin.cabal` to use others-extensionsHerbert Valerio Riedel2014-05-151-6/+12
| | | | | | | This replaces the previous `default-extensions` by per-file declared `{-# LANGUAGE ... #-}` pragmas. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Set cabal files to default-language:Haskell2010Herbert Valerio Riedel2014-05-141-4/+5
| | | | | | | This is a first step towards eliminating `default-extensions` in favour of per-file declared `{-# LANGUAGE ... #-}` pragmas. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Don't perform permission checks for scripts named with -ghci-script (#6017)Simon Marlow2014-03-271-0/+1
| | | | | | | | The user explicitly requested this script on the command-line, so it's unnecessary to require that the script is also owned by the user. Also, it is currently impossible to make a GHCi wrapper that invokes a custom script without first making a copy of the script to circumvent the permissions check, which seems wrong.
* Relax build-deps to allow upcoming `array-0.5.0.0`Herbert Valerio Riedel2013-10-111-1/+1
| | | | Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Remove dead code.Austin Seipp2013-08-221-4/+1
| | | | | | GHC >= 7.4 is needed to bootstrap. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* Update dependenciesIan Lynagh2012-11-301-1/+1
|
* Update dependency on directory.Paolo Capriotti2012-09-091-1/+1
|
* Use transformers directly, rather than using mtlIan Lynagh2012-05-191-1/+1
| | | | This means we no longer need mtl in a GHC tree.
* Update dependenciesIan Lynagh2012-02-221-1/+1
|
* MERGE from 7.4 branch: Update dependenciesIan Lynagh2012-02-081-2/+2
|
* Relax some dependenciesIan Lynagh2011-07-081-1/+1
|
* Rename "extra-gcc-opts" to "settings", and start generalising itIan Lynagh2011-04-211-1/+1
|
* Manually control more of the Cabal flags for the compiler and ghc packagesIan Lynagh2011-01-211-0/+2
| | | | | | 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-0/+2
| | | | | Now that we used cabal to configure the ghc-bin package they are no longer needed.
* Add NondecreasingIndentation extension to ghc-binIan Lynagh2011-01-171-0/+2
|
* Build system improvementsIan Lynagh2011-01-151-13/+7
| | | | | | | | | 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.
* Bump dependenciesIan Lynagh2010-09-171-1/+1
|
* Use haskeline, rather than editline, for line editing in ghciIan Lynagh2009-04-291-1/+15
|
* GHC new build system megapatchIan Lynagh2009-04-261-0/+3
|
* Generate ghc.cabal and ghc-bin.cabal with configureIan Lynagh2008-09-181-0/+39
This allows us to put the proper version number into them
View Lorry Controller Status