summaryrefslogtreecommitdiff
path: root/utils/ghc-cabal
Commit message (Collapse)AuthorAgeFilesLines
...
* ghc-cabal: accept EXTRA_HC_OPTS make variableSergei Trofimovich2016-09-021-1/+2
| | | | Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* Cabal submodule update.Edward Z. Yang2016-08-081-7/+6
| | | | | | | | | | | | | | | | | There's a substantial bump to the haddock.Cabal allocation stats, because we added 50% more modules, so of course allocations are going to increase 50%. (But perhaps this is indicative of some bad constant factor in Haddock related to modules.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: ggreif, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2442
* Remove identity update of field componentsConfigsGabor Greif2016-08-051-6/+1
| | | | | | | ... in LocalBuildInfo, getting rid of a TODO in the process. Turns out that componentsConfigs won't be a field in Cabal 2.0 any more, so this can be seen as a preparation for it.
* Trim all spaces after 'version:'Gabor Greif2016-08-051-1/+1
| | | | | | | ... that we grep out of libraries/Cabal/Cabal/Cabal.cabal This is necessary because the file got reformatted in the 'master' branch.
* Updates to handle new CabalEdward Z. Yang2016-06-301-8/+11
| | | | | | | | | | | | | | | | | | 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
* Update Cabal submodule to latest HEAD snapshotHerbert Valerio Riedel2016-03-091-1/+1
|
* Make bootstrapping more robustHerbert Valerio Riedel2016-02-162-1/+19
| | | | | | | | | | | | | | | Starting with GHC 8.0 we rely on GHC's native cabal macro generation. As a side-effect, this limits the packages in scope when compiling `ghc-cabal` for all bootstrapping GHCs. Reviewers: ezyang, austin, thomie, bgamari Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1897 GHC Trac Issues: #11413
* Update cabal_macros_boot.hHerbert Valerio Riedel2016-02-021-9/+20
| | | | | the MIN_VERSION_bytestring() macro is going to be needed for the upcoming binary update
* Switch from -this-package-key to -this-unit-id.Edward Z. Yang2016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A small cosmetic change, but we have to do a bit of work to actually support it: - Cabal submodule update, so that Cabal passes us -this-unit-id when we ask for it. This includes a Cabal renaming to be consistent with Unit ID, which makes ghc-pkg a bit more scrutable. - Build system is updated to use -this-unit-id rather than -this-package-key, to avoid deprecation warnings. Needs a version test so I resurrected the old test we had (sorry rwbarton!) - I've *undeprecated* -package-name, so that we are in the same state as GHC 7.10, since the "correct" flag will have only entered circulation in GHC 8.0. - I removed -package-key. Since we didn't deprecate -package-id I think this should not cause any problems for users; they can just change their code to use -package-id. - The package database is indexed by UNIT IDs, not component IDs. I updated the naming here. - I dropped the signatures field from ExposedModule; nothing was using it, and instantiatedWith from the package database field. - ghc-pkg was updated to use unit ID nomenclature, I removed the -package-key flags but I decided not to add any new flags for now. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: 23Skidoo, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1780
* Add Cabal synopses and descriptionsBen Gamari2016-01-052-3/+7
| | | | | | | | | | | | | | | | 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
* ghc-cabal: Bring back TRANSITIVE_DEP_NAMESBen Gamari2015-12-241-0/+1
| | | | | This is still needed by the Shake build system until things have been reworked to use Cabal directly.
* Remove unused/redundant fields from ghc-cabal.Edward Z. Yang2015-12-201-4/+0
| | | | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1662
* Update Cabal submodule to latest snapshotHerbert Valerio Riedel2015-12-161-3/+3
| | | | | This needs minor adaptations to ghc-cabal due to http://git.haskell.org/packages/Cabal.git/commitdiff/b39b906d05c409e4960ae15dbaca89664826a85f
* Update binary submodule to binary-0.8 snapshotHerbert Valerio Riedel2015-12-161-0/+1
| | | | | | | | | | | | This requires tweaking version constraints to allow this new major version of `binary`. Starting with binary-0.8, `Binary Version` is de-orphaned into `binary`. This requires some minor adaptations to remove/hide orphan instances. /cc @kolmodin Differential Revision: https://phabricator.haskell.org/D1635
* Make ghc-cabal's `System.Directory` import more robustHerbert Valerio Riedel2015-10-311-1/+1
| | | | | | | | Starting with directory-1.2.5 there will be a nameclash with `withCurrentDirectory` and `MIN_VERSION_filepath()` isn't available at bootstrap-time with the current GHC build-system. By using explicit import lists we avoid CPP altogether
* Build system: cleanup a few .cabal filesThomas Miedema2015-10-301-1/+1
|
* Rename PACKAGE_KEY and LIB_NAME in build system.Edward Z. Yang2015-10-141-4/+4
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Update Cabal to HEAD, IPID renamed to Component ID.Edward Z. Yang2015-10-141-42/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit contains a Cabal submodule update which unifies installed package IDs and package keys under a single notion, a Component ID. We update GHC to keep follow this unification. However, this commit does NOT rename installed package ID to component ID and package key to unit ID; the plan is to do that in a companion commit. - Compiler info now has "Requires unified installed package IDs" - 'exposed' is now expected to contain unit keys, not IPIDs. - Shadowing is no more. We now just have a very simple strategy to deal with duplicate unit keys in combined package databases: if their ABIs are the same, use the latest one; otherwise error. Package databases maintain the invariant that there can only be one entry of a unit ID. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari, hvr, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1184 GHC Trac Issues: #10714
* Library names, with Cabal submodule updateEdward Z. Yang2015-07-231-23/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A library name is a package name, package version, and hash of the version names of all textual dependencies (i.e. packages which were included.) A library name is a coarse approximation of installed package IDs, which are suitable for inclusion in package keys (you don't want to put an IPID in a package key, since it means the key will change any time the source changes.) - We define ShPackageKey, which is the semantic object which is hashed into a PackageKey. You can use 'newPackageKey' to hash a ShPackageKey to a PackageKey - Given a PackageKey, we can lookup its ShPackageKey with 'lookupPackageKey'. The way we can do this is by consulting the 'pkgKeyCache', which records a reverse mapping from every hash to the ShPackageKey. This means that if you load in PackageKeys from external sources (e.g. interface files), you also need to load in a mapping of PackageKeys to their ShPackageKeys so we can populate the cache. - We define a 'LibraryName' which encapsulates the full depenency resolution that Cabal may have selected; this is opaque to GHC but can be used to distinguish different versions of a package. - Definite packages don't have an interesting PackageKey, so we rely on Cabal to pass them to us. - We can pretty-print package keys while displaying the instantiation, but it's not wired up to anything (e.g. the Outputable instance of PackageKey). Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1056 GHC Trac Issues: #10566
* Make $1 in $1_$2_$3_FOO actually be directory.Edward Z. Yang2015-06-231-4/+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
* Fix #10551 by using LIB_NAMES.Edward Z. Yang2015-06-221-5/+0
| | | | | | | | | | | | | | | | | | 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-8/+9
| | | | | | | | | | | | | | | | 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-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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
* ghc-cabal: don't warn about missing cabal fieldsThomas Miedema2015-06-041-5/+3
| | | | | | | | | | | | | | Only print and exit on errors. Warnings of the type 'PackageDistSuspicious' are not very useful. The following show up in the build logs currently: * The 'license' field is missing. * No 'maintainer' field * No 'category' field * 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit and not just imposing longer compile times on your users. Differential Revision: https://phabricator.haskell.org/D944
* Drop old integer-gmp-0.5 from GHC source treeHerbert Valerio Riedel2015-03-311-4/+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
* Minor bump `base` version to 4.8.1.0Herbert Valerio Riedel2015-03-231-1/+7
| | | | | We've accumulated enough to justify a minor version bump to 4.8.1.0, but not enough to justify a major version bump yet as far as I can see.
* 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
* Update Cabal submodule to latest 1.22 snapshotEdward Z. Yang2015-03-111-0/+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
* Update Cabal submodule to 1.22 versionHerbert Valerio Riedel2014-12-182-3/+3
|
* Update `binary` submodule to final 0.7.2.3 releaseHerbert Valerio Riedel2014-12-142-0/+22
| | | | | | This also introduces a "bootstrap" `cabal_macros.h` header to provide the `MIN_VERSION_base()` macro during Cabal bootstrapping which as it is now used by `binary`.
* Implement new integer-gmp2 from scratch (re #9281)Herbert Valerio Riedel2014-11-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is done as a separate `integer-gmp2` backend library because it turned out to become a complete rewrite from scratch. Due to the different (over)allocation scheme and potentially different accounting (via the new `{shrink,resize}MutableByteArray#` primitives), some of the nofib benchmarks actually results in increased allocation numbers (but not necessarily an increase in runtime!). I believe the allocation numbers could improve if `{resize,shrink}MutableByteArray#` could be optimised to reallocate in-place more efficiently. Here are the more apparent changes in the latest nofib comparision between `integer-gmp` and `integer-gmp2`: ------------------------------------------------------------------ Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------ ... bernouilli +1.6% +15.3% 0.132 0.132 0.0% ... cryptarithm1 -2.2% 0.0% -9.7% -9.7% 0.0% ... fasta -0.7% -0.0% +10.9% +10.9% 0.0% ... kahan +0.6% +38.9% 0.169 0.169 0.0% ... lcss -0.7% -0.0% -6.4% -6.4% 0.0% ... mandel +1.6% +33.6% 0.049 0.049 0.0% ... pidigits +0.8% +8.5% +3.9% +3.9% 0.0% power +1.4% -23.8% -18.6% -18.6% -16.7% ... primetest +1.3% +50.1% 0.085 0.085 0.0% ... rsa +1.6% +53.4% 0.026 0.026 0.0% ... scs +1.2% +6.6% +6.5% +6.6% +14.3% ... symalg +1.0% +9.5% 0.010 0.010 0.0% ... transform -0.6% -0.0% -5.9% -5.9% 0.0% ... ------------------------------------------------------------------ Min -2.3% -23.8% -18.6% -18.6% -16.7% Max +1.6% +53.4% +10.9% +10.9% +14.3% Geometric Mean -0.3% +1.9% -0.8% -0.8% +0.0% (see P35 / https://phabricator.haskell.org/P35 for full report) By default, `INTEGER_LIBRARY=integer-gmp2` is active now, which results in the package `integer-gmp-1.0.0.0` being registered in the package db. The previous `integer-gmp-0.5.1.0` can be restored by setting `INTEGER_LIBRARY=integer-gmp` (but will probably be removed altogether for GHC 7.12). In-tree GMP support has been stolen from the old `integer-gmp` (while unpatching the custom memory-allocators, as well as forcing `-fPIC`) A minor hack to `ghc-cabal` was necessary in order to support two different `integer-gmp` packages (in different folders) with the same package key. There will be a couple of follow-up commits re-implementing some features that were dropped to keep D82 minimal, as well as further clean-ups/improvements. More information can be found via #9281 and https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2 Reviewed By: austin, rwbarton, simonmar Differential Revision: https://phabricator.haskell.org/D82
* Use bracket in `withCurrentDirectory`Konstantin Zudov2014-11-071-6/+3
| | | | | | | | | | | | Summary: There was a comment about that. Seems like a better behaviour. Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D419
* Update Cabal submodule & ghc-pkg to use new module re-export typesEdward Z. Yang2014-09-242-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main change is that Cabal changed the representation of module re-exports to distinguish reexports in source .cabal files versus re-exports in installed package registraion files. Cabal now also does the resolution of re-exports to specific installed packages itself, so ghc-pkg no longer has to do this. This is a cleaner design overall because re-export resolution can fail so it is better to do it during package configuration rather than package registration. It also simplifies the re-export representation that ghc-pkg has to use. Add extra ghc-pkg sanity check for module re-exports and duplicates For re-exports, check that the defining package exists and that it exposes the defining module (or for self-rexport exposed or hidden modules). Also check that the defining package is actually a direct or indirect dependency of the package doing the re-exporting. Also add a check for duplicate modules in a package, including re-exported modules. Test Plan: So far the sanity checks are totally untested. Should add some test case to make sure the sanity checks do catch things correctly, and don't ban legal things. Reviewers: austin, duncan Subscribers: angerman, simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D183 GHC Trac Issues:
* Package keys (for linking/type equality) separated from package IDs.Edward Z. Yang2014-08-051-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch set makes us no longer assume that a package key is a human readable string, leaving Cabal free to "do whatever it wants" to allocate keys; we'll look up the PackageId in the database to display to the user. This also means we have a new level of qualifier decisions to make at the package level, and rewriting some Safe Haskell error reporting code to DTRT. Additionally, we adjust the build system to use a new ghc-cabal output Make variable PACKAGE_KEY to determine library names and other things, rather than concatenating PACKAGE/VERSION as before. Adds a new `-this-package-key` flag to subsume the old, erroneously named `-package-name` flag, and `-package-key` to select packages by package key. RFC: The md5 hashes are pretty tough on the eye, as far as the file system is concerned :( ToDo: safePkg01 test had its output updated, but the fix is not really right: the rest of the dependencies are truncated due to the fact the we're only grepping a single line, but ghc-pkg is wrapping its output. ToDo: In a later commit, update all submodules to stop using -package-name and use -this-package-key. For now, we don't do it to avoid submodule explosion. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D80
* Module reexports, fixing #8407.Edward Z. Yang2014-07-251-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The general approach is to add a new field to the package database, reexported-modules, which considered by the module finder as possible module declarations. Unlike declaring stub module files, multiple reexports of the same physical package at the same name do not result in an ambiguous import. Has submodule updates for Cabal and haddock. NB: When a reexport renames a module, that renaming is *not* accessible from inside the package. This is not so much a deliberate design choice as for implementation expediency (reexport resolution happens only when a package is in the package database.) TODO: Error handling when there are duplicate reexports/etc is not very well tested. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Conflicts: compiler/main/HscTypes.lhs testsuite/.gitignore utils/haddock
* Update Cabal submodule to HEAD (1.21)Edward Z. Yang2014-07-211-1/+1
| | | | This reverts commit f23b2129aca24beb4ece0d5915f67c448dc64ae4.
* Revert "Update Cabal submodule to HEAD (1.21)"Edward Z. Yang2014-07-201-1/+1
| | | | | This reverts commit af28e61c7e84b8eb89fdfd9671af83a2a13f554a. We'll wait until it's possible to bootstrap from 7.6 out of the box.
* Update Cabal submodule to HEAD (1.21)Edward Z. Yang2014-07-181-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Set cabal files to default-language:Haskell2010Herbert Valerio Riedel2014-05-141-1/+2
| | | | | | | 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>
* Use import list to hide new System.Exit.dieHerbert Valerio Riedel2014-04-211-1/+1
| | | | | | | | | Soon, System.Exit will export the new `die` (see #9016) which would clash with Cabal's own `die` implementation. This commit provides forward-compatiblity. This also updates the Cabal submodule which requires a similiar fix. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Update Cabal submodule to tip of v1.20 branchHerbert Valerio Riedel2014-04-162-1/+11
| | | | | | | | | | | | | | | | | | | 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>
* Include SRC_CC_OPTS and SRC_LD_OPTS when compiling ghc-cabalSimon Marlow2014-03-271-2/+4
|
* ghc-cabal: force use of UTF8 when writing out `haddock-prologue.txt`Herbert Valerio Riedel2014-03-231-1/+7
| | | | | | | | This unbreaks the GHC build if a non-UTF8 locale such as LANG=C is active See also haskell/cabal#1721 and haskell/haddock#286 Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-012-4/+4
|
* Cause "make install" to install dynamic libraries (#8194)Bryan O'Sullivan2013-09-151-4/+6
| | | | | | Our special ghc-cabal command needs to be told that we are building with dynamic library support when it does its copying. We do so by passing an extra parameter from ghc.mk.
* Sync Cabal to upstream version 1.18 pre-releaseHerbert Valerio Riedel2013-08-262-7/+8
| | | | | | Apart from bumping build-dep version bounds, `ghc-cabal` is adapted to some minor Cabal API changes, and `bin-package-db` is made aware of Cabal's recently added AGPL licence support.
* Fix the GHC package DLL-splittingIan Lynagh2013-05-141-6/+14
| | | | | | | 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-19/+17
| | | | | | 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).
* More work towards dynamic programs on WindowsIan Lynagh2013-05-121-0/+1
| | | | | | | | | | | | | | | | | | | Dynamic GHC is now working in-place, but pathologically slow due to the DLL split. (GHC assumes that all intra-package calls are in the same DLL, but that isn't true when we split the GHC package into 2 DLLs. That means that GHC's startup time is around 22 seconds, as it is doing run-time linking). Also, ghci isn't actually working yet: $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.7.20130512: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... <command line>: can't load .so/.DLL for: HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL) ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be found.
* Fix the inplace name of ghc-cabalIan Lynagh2013-04-251-1/+1
| | | | We had inplace/bin/ghc-cabalghc-cabal
View Lorry Controller Status