summaryrefslogtreecommitdiff
path: root/utils/ghc-cabal/Main.hs
Commit message (Collapse)AuthorAgeFilesLines
* make build system: RTS should use dist-install not distJohn Ericson2021-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This is the following find and replace: - `rts/dist` -> `rts/dist-install` # for paths - `rts_dist` -> `rts_dist-install` # for make rules and vars - `,dist` -> `,dist-install` # for make, just in rts/ghc.mk` Why do this? Does it matter when the RTS is just built once? The answer is, yes, I think it does, because I want the distdir--stage correspondence to be consistent. In particular, for #17191 and continuing from d5de970dafd5876ef30601697576167f56b9c132 I am going to make the headers (`rts/includes`) increasingly the responsibility of the RTS (hence their new location). However, those headers are current made for multiple stages. This will probably become unnecessary as work on #17191 progresses and the compiler proper becomes more of a freestanding cabal package (e.g. a library that can be downloaded from Hackage and built without any autoconf). However, until that is finished, we have will transitional period where the RTS and headers need to agree on dirs for multiple stages. I know the make build system is going away, but it's not going yet, so I need to change it to unblock things :).
* Properly escape arguments in ghc-cabalZubin Duggal2021-08-031-3/+17
|
* import Data.List with explicit import listOleg Grenrus2021-03-311-1/+1
|
* Allocate Adjustors and mark them readable in two stepsMoritz Angermann2021-03-291-1/+1
| | | | | | | | | This drops allocateExec for darwin, and replaces it with a alloc, write, mark executable strategy instead. This prevents us from trying to allocate an executable range and then write to it, which X^W will prohibit on darwin. This will *only* work if we can use mmap.
* Bump time submodule to 1.11.1Ben Gamari2020-11-221-1/+3
| | | | | | Also bumps directory, Cabal, hpc, time, and unix submodules. Closes #18847.
* Disable two warnings for files that trigger themTom Ellis2020-01-271-0/+1
| | | | | | incomplete-uni-patterns and incomplete-record-updates will be in -Wall at a future date, so prepare for that by disabling those warnings on files that trigger them.
* Update to Cabal submodule to v3.2.0.0-alpha3Oleg Grenrus2020-01-041-4/+5
| | | | | Metric Increase: haddock.Cabal
* Windows: Update tarballs to GCC 9.2 and remove MAX_PATH limit.Tamar Christina2019-10-201-2/+19
|
* ghc-cabal: Use fromFlagOrDefault instead of fromFlagBen Gamari2019-07-211-2/+2
| | | | | As fromFlag is partial. The only case where we used fromFlag is when determining whether to strip libraries; we now assume that we shouldn't.
* Bump containers submodule to v0.6.2.1Ben Gamari2019-06-251-4/+5
|
* Bump Cabal submoduleBen Gamari2019-06-121-3/+18
| | | | | | | (cherry picked from commit ff438786613f07df9b2d43eaeac49b13815d849d) Metric Increase: haddock.Cabal
* Register 'haddockHTMLs' for inplace buildsAlec Theriault2018-07-121-1/+0
|
* Bump Cabal submodule to 2.2Moritz Angermann2018-03-031-5/+26
| | | | | | | | | | | | | | Requires some ghc-cabal changes as well. Test Plan: ./validate Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: hsyl20, erikd, alpmestan, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4453
* Update Cabal submoduleOleg Grenrus2018-01-211-3/+3
| | | | | | | | | | | | | | | | - Cabal-2.2 uses SPDX license identifiers, so I had to update `cabal-version: 2.1` packages `license: BSD3` to `license: BSD-3-Clause` - `ghc-cabal` used old ReadP parsec, now it uses `parsec` too - InstalledPackageInfo pretty-printing have changed a little, fields with default values aren't printed. This can be changed in `Cabal` still, but I haven't found problems with omitting them. Note: `BSD-3-Clause` is parsed as "name = BSD, version = 3" by old parser (because 3-Clause looks like version 3 with tag Clause). If you see *"BSD-3" is not a valid license*, then something is using old parser still. Fixes #9885.
* Bump Cabal submoduleBen Gamari2017-12-221-3/+3
|
* GHC.Prim use virtual-modulesMoritz Angermann2017-11-181-15/+1
| | | | | | | | | | | | | | | Stop the GHC.Prim madness with `virtual-module` support from cabal. Needs https://github.com/haskell/cabal/pull/4875. Bumps submodule libraries/Cabal to include the necessary logic for `virtual-module`. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4179
* Adds cmm-sources to baseMoritz Angermann2017-11-111-1/+2
| | | | | | | | | | | | Bumps Cabal submodule. Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4176
* Update Win32 version for GHC 8.4.Tamar Christina2017-11-091-3/+4
| | | | | | | | | | | | | | | | | | | Update to Win32 2.6 which is the expected version release for 8.4 This involves moving Cabal forward which brings some backwards incompatible changes that needs various fixups. Bump a bunch of submodules Test Plan: ./validate Reviewers: austin, bgamari, angerman Reviewed By: bgamari, angerman Subscribers: angerman, thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D4133
* Revert "ghc-cabal: Inline removed function ..."Tamar Christina2017-10-251-8/+1
| | | | This reverts commit f744261ad25942e8a747821fc468f1a21c9c705c.
* ghc-cabal: Inline removed function from Cabal.Tamar Christina2017-10-251-1/+8
|
* Remove dll-split.Tamar Christina2017-08-291-33/+6
| | | | | | | | | | | | | | | | | | | | 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
* Update Cabal submodule, with necessary wibbles.Edward Z. Yang2017-04-261-1/+2
| | | | | | | | | | | | Test Plan: validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3501
* Update ghc-cabal command line usage text.Edward Z. Yang2016-12-211-3/+7
| | | | | | | | | | | | | | | Summary: Old usage text was horribly out-of-date. Now updated! Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: none Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2889
* Support for abi-depends for computing shadowing.Edward Z. Yang2016-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a complete fix based off of ed7af26606b3a605a4511065ca1a43b1c0f3b51d for handling shadowing and out-of-order -package-db flags simultaneously. The general strategy is we first put all databases together, overriding packages as necessary. Once this is done, we successfully prune out broken packages, including packages which depend on a package whose ABI differs from the ABI we need. Our check gracefully degrades in the absence of abi-depends, as we only check deps which are recorded in abi-depends. Contains time and Cabal submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: niteria, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2846 GHC Trac Issues: #12485
* Omit unnecessary linker flagsSimon Marlow2016-11-031-3/+0
| | | | | | | | | | | | | | | | | | | | | Summary: This omits -L and -l flags from the linker command line that shouldn't be necessary because GHC will already add them via the -package-id flags we pass. This also reverts part of 90538d86af579595987826cd893828d6f379f35a that rearranges the linker command line and causes some knock-on problems (see D2618). Test Plan: validate (need to validate on Windows too) Reviewers: Phyx, bgamari, niteria, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2639 GHC Trac Issues: #12738
* Add and use a new dynamic-library-dirs field in the ghc-pkg infoDuncan Coutts2016-10-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Build systems / package managers want to be able to control the file layout of installed libraries. In general they may want/need to be able to put the static libraries and dynamic libraries in different places. The ghc-pkg library regisrtation needs to be able to handle this. This is already possible in principle by listing both a static lib dir and a dynamic lib dir in the library-dirs field (indeed some previous versions of Cabal did this for shared libs on ELF platforms). The downside of listing both dirs is twofold. There is a lack of precision, if we're not careful with naming then we could end up picking up the wrong library. The more immediate problem however is that if we list both directories then both directories get included into the ELF and Mach-O shared object runtime search paths. On ELF this merely slows down loading of shared libs (affecting prog startup time). On the latest OSX versions this provokes a much more serious problem: that there is a rather low limit on the total size of the section containing the runtime search path (and lib names and related) and thus listing any unnecessary directories wastes the limited space. So the solution in this patch is fairly straightforward: split the static and dynamic library search paths in the ghc-pkg db and its use within ghc. This is a traditional solution: pkg-config has the same static / dynamic split (though it describes in in terms of private and public, but it translates into different behaviour for static and dynamic linking). Indeed it would make perfect sense to also have a static/dynamic split for the list of the libraries to use i.e. to have dynamic variants of the hs-libraries and extra-libraries fields. These are not immediately required so this patch does not add it, but it is a reasonable direction to follow. To handle compatibility, if the new dynamic-library-dirs field is not specified then its value is taken from the library-dirs field. Contains Cabal submodule update. Test Plan: Run ./validate Get christiaanb and carter to test it on OSX Sierra, in combination with Cabal/cabal-install changes to the default file layout for libraries. Reviewers: carter, austin, hvr, christiaanb, bgamari Reviewed By: christiaanb, bgamari Subscribers: ezyang, Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2611 GHC Trac Issues: #12479
* Update Cabal submodule to latest version.Edward Z. Yang2016-10-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: Note that Cabal needs one more bugfix which is in PR to fix GHC bootstrapping. But the rest of the patch is ready for review. Needs a filepath submodule update because cabal check became more strict. This patch handles the abstract-ification of Version and PackageName. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2555
* 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.
* 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
* 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-051-1/+1
| | | | | | | | | | | | | | | | 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
* 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
* 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
* 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-181-2/+2
|
* 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-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: