summaryrefslogtreecommitdiff
path: root/utils/ghc-pkg
Commit message (Collapse)AuthorAgeFilesLines
* Update Cabal submodule & ghc-pkg to use new module re-export typesEdward Z. Yang2014-09-241-203/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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:
* Make Applicative a superclass of MonadAustin Seipp2014-09-091-0/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This includes pretty much all the changes needed to make `Applicative` a superclass of `Monad` finally. There's mostly reshuffling in the interests of avoid orphans and boot files, but luckily we can resolve all of them, pretty much. The only catch was that Alternative/MonadPlus also had to go into Prelude to avoid this. As a result, we must update the hsc2hs and haddock submodules. Signed-off-by: Austin Seipp <austin@well-typed.com> Test Plan: Build things, they might not explode horribly. Reviewers: hvr, simonmar Subscribers: simonmar Differential Revision: https://phabricator.haskell.org/D13
* Fix a few minor issues spotted in code reviewDuncan Coutts2014-08-291-2/+1
|
* Address a number of Edward's code review commentsDuncan Coutts2014-08-291-6/+11
| | | | Some others addressed as part of other recent patches.
* Fix string conversions in ghc-pkg to be correct w.r.t. UnicodeDuncan Coutts2014-08-291-4/+5
| | | | | Similar change to that on the ghc library side in the previous patch. The BinaryStringRep class has to use a ByteString in UTF8 encoding.
* Fix long lines and trailing whitespaceDuncan Coutts2014-08-291-35/+48
| | | | in the previous patches in this series
* Fix warnings arising from the package db refactoringDuncan Coutts2014-08-291-5/+1
|
* Move Cabal Binary instances from bin-package-db to ghc-pkg itselfDuncan Coutts2014-08-291-5/+147
| | | | | The ghc-pkg program of course still depends on Cabal, it's just the bin-package-db library (shared between ghc and ghc-pkg) that does not.
* Use ghc-local types for packages, rather than Cabal typesDuncan Coutts2014-08-291-6/+54
| | | | | | | | Also start using the new package db file format properly, by using the ghc-specific section. This is the main patch in the series for removing the compiler's dep on the Cabal lib.
* Introduce new file format for the package database binary cacheDuncan Coutts2014-08-291-22/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new format is to make it possible for the compiler to not depend on the Cabal library. The new cache file format contains more or less the same information duplicated in two different sections using different representations. One section is basically the same as what the package db contains now, a list of packages using the types defined in the Cabal library. This section is read back by ghc-pkg, and used for things like ghc-pkg dump which have to produce output using the Cabal InstalledPackageInfo text representation. The other section is a ghc-local type which contains a subset of the information from the Cabal InstalledPackageInfo -- just the bits that the compiler cares about. The trick is that the compiler can read this second section without needing to know the representation (or types) of the first part. The ghc-pkg tool knows about both representations and writes both. This patch introduces the new cache file format but does not yet use it properly. More patches to follow. (As of this patch, the compiler reads the part intended for ghc-pkg so it still depends on Cabal and the ghc-local package type is not yet fully defined.)
* Improve the ghc-pkg warnings for missing and out of date package cache filesDuncan Coutts2014-08-291-23/+38
| | | | | | In particular, report when it's missing, and also report it for ghc-pkg check. Also make the warning message more explicit, that ghc will not be able to read these dbs, even though ghc-pkg may be able to.
* Drop support for single-file style package databasesDuncan Coutts2014-08-291-58/+9
| | | | | | | | | | | | | | | | Historically the package db format was a single text file in Read/Show format containing [InstalledPackageInfo]. For several years now the default format has been a directory with one file per package, plus a binary cache. The old format cannot be supported under the new scheme where the compiler will not depend on the Cabal library (because it will not have access to the InstalledPackageInfo type) so we must drop support. It would still technically be possible to support a single text file style db (but containing a different type), but there does not seem to be any compelling reason to do so. (Part of preparitory work for removing the compiler's dep on Cabal)
* Simplify conversion in binary serialisation of ghc-pkg dbDuncan Coutts2014-08-291-4/+3
| | | | | | | We can serialise directly, without having to convert some fields to string first. (Part of preparitory work for removing the compiler's dep on Cabal)
* Have ghc-pkg use an old-style package key when it's not provided.Edward Z. Yang2014-08-131-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | Summary: When this occurs, it means that the user is using an old version of Cabal. In that case, don't barf out: just go ahead and install it as an old-style package key. The user won't be able to link multiple versions together, but that should not be a problem because their Cabal can't handle it anyway. What happens if old-style are mixed up with new-style? Well, currently with Cabal, it's indistinguishable. However, if at some later point we add private dependencies, libraries compiled with old style linker names are incompatible with each other. We'll cross that road when we come to it. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: tibbe, hvr, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D154
* Disable ghc-pkg accepting multiple package IDs (differing package keys) for now.Edward Z. Yang2014-08-051-5/+4
| | | | | | | | | | | | | Duncan requested that ghc-pkg not accept duplicate package IDs (foo-0.1) by default until the higher level tools can accommodate it. Until then you'll need to use the --multi-instance flag to install multiple copies in the package database. I think reusing the --multi-instance flag is dodgy, because that can be used to cause duplicate package keys; but there is a mode of use of the database where package keys are unique. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Package keys (for linking/type equality) separated from package IDs.Edward Z. Yang2014-08-051-13/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support ghc-pkg --ipid to query package ID.Edward Z. Yang2014-07-281-34/+56
| | | | | | | | | | | | Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: hvr, simonmar, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D98
* Module reexports, fixing #8407.Edward Z. Yang2014-07-252-3/+56
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Documentation for substringCheck.Edward Z. Yang2014-07-211-0/+22
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* [ghc-pkg] Fix #5442 by using the flag db stack to modify packages.Edward Z. Yang2014-07-211-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, the full database stack was used for ghc-pkg to modify packages, which meant that commands like 'ghc-pkg unregister --user' worked the same as 'ghc-pkg unregister'. Since package modification is a "read and write" operation, we should use the flag db stack (which is currently used for reads) to determine which database to update. There is also a new flag --user-package-db, which lets you explicitly set the user database (as seen by --user). This was mostly added to aid in testing, but could be useful for end users as well. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D84
* ghc-pkg register/update --enable-multi-instanceAustin Seipp2014-07-021-13/+36
| | | | | | | | | | | | | | | | | | | | | Summary: New flag to ghc-pkg register/update to lift the restriction on multiple instances of the same package version being in a db at once. Lifting the restriction is easy. The tricky bit is checking ghc does something sensible, but from the reading of the code it should treat such instances the same way it does with multiple instances between multiple DBs. We'll also need a way to unregister by installed package id. Test Plan: need to test that ghc is doing what we expect, at least if you use it like -hide-all-packages -package-id this -package-id that Reviewers: ezyang, simonmar Reviewed By: simonmar Subscribers: relrod Projects: #ghc Differential Revision: https://phabricator.haskell.org/D32
* Avoid NondecreasingIndentation syntax in ghc-pkgHerbert Valerio Riedel2014-05-152-31/+31
| | | | | | | | | This also makes ghc-pkg.cabal `default-extensions`-free NB: Printing this commit via `git show --ignore-all-spaces` shows the only non-whitespaces changes are in `ghc-pkg.cabal` Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Remove LANGUAGE pragrams implied by Haskell2010Herbert Valerio Riedel2014-05-141-1/+1
| | | | | | | | | Haskell2010 implies (at least) EmptyDataDecls, ForeignFunctionInterface, PatternGuards, DoAndIfThenElse, and RelaxedPolyRec. This is a follow-up to dd92e2179e3171a0630834b773c08d416101980d Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Set cabal files to default-language:Haskell2010Herbert Valerio Riedel2014-05-141-2/+3
| | | | | | | 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>
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-012-4/+4
|
* Fix AMP warnings.Austin Seipp2013-09-111-0/+8
| | | | | Authored-by: David Luposchainsky <dluposchainsky@gmail.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Fix ghc-pkg list --simple-output not being alphabetical (#8245).Niklas Hambüchen2013-09-061-8/+9
| | | | | | | | | It was sorted by version number so far. I also added a sort to the normal output (without --simple-output) since the source it comes from does not guarantee sortedness. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* Update the package database directory's timestamps when rebuilding the ↵Geoffrey Mainland2013-06-241-0/+4
| | | | | | | | | | package cache. I was seeing many "WARNING: cache is out of date" errors during validation claiming that my package cache was out of date. This patch eliminates those errors by ensuring that when we rebuild the package cache, the modification time of the directory containing the package database is set to be the same as the modification time of the cache.
* When verbose, give more information about cache statusIan Lynagh2013-05-301-17/+35
|
* Small refactoring in ghc-pkgIan Lynagh2013-04-281-6/+4
|
* Remove some old "backwards compatibility" codeIan Lynagh2013-04-281-24/+4
| | | | | | It was marked as "backwards compatibility" in 2006, so I think can be removed now. It allowed using old field names when looking at fields with ghc-pkg.
* Make "ghc-pkg field pkg field --simple-output" do something usefulIan Lynagh2013-04-281-16/+20
| | | | It used to just ignore the --simple-output flag
* Automatically add the $(exeext) to program namesIan Lynagh2013-03-031-4/+2
| | | | | | | 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 more of the automatically generated INPLACE variablesIan Lynagh2013-03-031-1/+1
|
* Rename $(Windows) to $(Windows_Host)Ian Lynagh2013-03-011-1/+1
|
* Define utils/ghc-pkg_dist_PROG correctly for WindowsIan Lynagh2013-02-161-3/+1
|
* Build the stage0 ghc-pkg with CabalIan Lynagh2013-02-161-56/+13
| | | | | | | This solves the problem of how to define MIN_VERSION_base for the binary package. Also fixed a couple of build system bugs along the way.
* Build system tweak: Do the package checks at configure timeIan Lynagh2013-02-151-1/+1
| | | | | | | | 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.
* Stop using the deprecated System.CmdIan Lynagh2013-02-151-2/+1
|
* install ghc-pkg correctly when Stage1Only=YES (#7639)Simon Marlow2013-02-051-20/+27
|
* Try to make ghc-pkg and ghc-cabal use the same flags when bootstrapping.Simon Marlow2013-02-011-1/+0
| | | | | They share modules in Cabal, and unless they use exactly the same flags GHC recompiles the modules.
* Tidy up cross-compilingSimon Marlow2013-01-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=<..>
* Update dependenciesIan Lynagh2012-11-301-1/+1
|
* Make ghc-pkg print less on error.Ben Millwood2012-11-301-5/+6
|
* fix typo, courtesy of Jon Cave, thanks!Gabor Greif2012-11-081-1/+1
|
* Fix a makefile ruleIan Lynagh2012-10-291-1/+1
|
* Move ghc-pkg's generated Version.hs inside the dist directoriesIan Lynagh2012-10-291-6/+9
|
* Make "ghc-pkg check" check for prof and dyn ways, as well as vanillaIan Lynagh2012-10-251-17/+23
| | | | | In particular, this fixes it if we are using dynamic libraries by default and don't build the vanilla way.
* Remove an outdated commentIan Lynagh2012-10-251-1/+1
|
* ghc-pkg: Print something when no packages are found; fixes #6119Ian Lynagh2012-10-111-1/+4
| | | | | | | | | | We used to say $ ghc-pkg list blargle /usr/local/lib/ghc-7.4.1/package.conf.d which may imply that blargle was found in /usr/local/lib/ghc-7.4.1/package.conf.d
View Lorry Controller Status