| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Authored-by: David Luposchainsky <dluposchainsky@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
It used to just ignore the --simple-output flag
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
In particular, this fixes it if we are using dynamic libraries by
default and don't build the vanilla way.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
| |
Really we ought to support all the old flags, but warn that they
are deprecated.
|
| | |
|
| |
|
|
|
|
|
|
| |
Rename package database flags in both GHC and ghc-pkg so that they are
consistent with Cabal nomenclature.
Add a version check to the build system so that the correct set of
package db flags are used when the bootstrapping GHC has version < 7.5.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It was only working when followed by something, e.g. "$topdir/base".
|
| | |
|
| |
|
|
|
| |
I'd naively assumed that the haddock-html field would only use the
$httptopdir variable. Hopefully this will fix the windows build.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tools handling installed packages need to be able to interpret the
paths which are relative to the ${pkgroot} which means they need to
know the value of ${pkgroot}. With ghc-pkg this is not always obvious
since ghc-pkg does not currently have any way machine interface for
reporting the location of its package dbs (global, user). The solution
we have arrived at is simply to emit the pkgroot as an extra field
when it is needed.
There are two cases:
* --no-expand-pkgroot: ghc-pkg dump/describe will not expand the
${pkgroot} var, so it will appear literally in the output and the
pkgroot field will be generated so that tools know what value to
use for the ${pkgroot}.
* --expand-pkgroot: ghc-pkg dump/describe will expand the ${pkgroot}
and ${pkgrooturl} vars and will not generate the pkgroot field.
The defaults are:
* ghc-pkg dump/describe --no-expand-pkgroot
* ghc-pkg field --expand-pkgroot
|
| |
|
|
|
|
|
| |
The haddock-html and haddock-interface fields are now checked
as well. Had to fix up ghc-cabal as it used relative paths for
the inplace package's haddock-html. It turns out that these
were never used so it could simply be omitted.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically ghc implemented relocatable packages by allowing
"$topdir" in the package registration info and having ghc expand
this with its notion of $topdir. The topdir refers to where ghc
itself is installed (specifically the libdir).
The ${pkgroot} spec takes this idea and makes it portable.
(http://www.haskell.org/pipermail/libraries/2009-May/011772.html)
Instead of paths relative to where ghc is installed, they can be
relative to the package database itself. Thus it is no longer a
ghc-specific idea and can work for package collections other than
the global package db.
|
| |
|
|
|
|
| |
It was never a universal solution. It only worked with the GNU linker.
It has not been used by Cabal for ages. GHCi can now load .a files so
it will not be needed in future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For shell-based build systems the feature is still available as:
ghc-pkg register --expand-env-vars
Historically, ghc-pkg allowed environment variables to appear in the
input files for ghc-pkg register. They are not stored in the package
database but are expanded upon registration. This feature helped for
build systems based on makefiles and shell scripts. These days the
vast majority of such files are generated by Cabal and we don't want
any ${name} strings (e.g. perhaps in a package description) getting
accidentally interpreted as an environment variable.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
GHCi libs are no longer necessary, as we can use the .a or .so versions
instead.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
