| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
For 7.2 we ignore the trust value in the package info we get given,
and always trust packages
|
|
|
|
| |
Duncan says that Cabal isn't guaranteed to be warning-free.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
It used to take a whole DynFlags, but that meant we had to
create a DynFlags with (panic "No settings") for settings, as
we didn't have any real settings.
Now we just pass the LogAction, which is all that it actually needed.
The default is exported from DynFlags as defaultLogAction.
|
|
|
|
|
|
| |
There was an extra % in the strftime string used in the fingerprint
script to name the output files. It worked fine in python 2.6 on mac
os, but was producing bad file names in python 2.7 on linux.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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.
|
|
|
|
|
| |
makes it easier to remove everything built with stage1 in cases where
the build system or GHC wrongly thinks everything is up to date.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| | |
heuristics work better. Also removed the old unused "needs_wrapper"
predicate for primops. This helps with #4978.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This commit adds fingerprint.py python script that can be used to
create and restore "fingerprints" of a ghc repo configuration. A
fingerprint is a list of (sub-repo, commit) pairs. It can be used in
place of git submodules to record and reinstate the entire commit
state of the git repos used by ghc.
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/
| |
| |
| |
| | |
Fixed conflicts:
compiler/iface/IfaceSyn.lhs
compiler/typecheck/TcSMonad.lhs
|
| | |
|
|/
|
|
| |
They belonged to the old generic deriving mechanism, so they can go. Adapted a lot of code as a consequence.
|
|
|
|
|
|
| |
Stops us having to temporarily have a panic in the DynFlags.
We still need a panic in the DynFlags used for the top-level
error handler, though.
|
| |
|
|
|
|
| |
otherwise we repeatedly try to rebuild ghc-pkg if ghc-cabal is newer.
|
| |
|
| |
|
| |
|
|
|
|
| |
Make sure they contain no single quotes, leading spaces, or trailing spaces.
|
|
|
|
|
|
|
|
|
| |
The DEP_INCLUDE_DIRS and DEP_LIB_DIRS variables always contain
single-quote dirs, so we can use e.g.
$(subst $(space)',$(space)-L',$(space)$($1_$2_DEP_LIB_DIRS_SINGLE_QUOTED))
to add -L to the front of each dir. I've appended "_SINGLE_QUOTED" to
the variable names so we don't accidentally add bare directories to
them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the new code generator to make use of the Hoopl package
for dataflow analysis. Hoopl is a new boot package, and is maintained
in a separate upstream git repository (as usual, GHC has its own
lagging darcs mirror in http://darcs.haskell.org/packages/hoopl).
During this merge I squashed recent history into one patch. I tried
to rebase, but the history had some internal conflicts of its own
which made rebase extremely confusing, so I gave up. The history I
squashed was:
- Update new codegen to work with latest Hoopl
- Add some notes on new code gen to cmm-notes
- Enable Hoopl lag package.
- Add SPJ note to cmm-notes
- Improve GC calls on new code generator.
Work in this branch was done by:
- Milan Straka <fox@ucw.cz>
- John Dias <dias@cs.tufts.edu>
- David Terei <davidterei@gmail.com>
Edward Z. Yang <ezyang@mit.edu> merged in further changes from GHC HEAD
and fixed a few bugs.
|
|
|
|
| |
Avoids repeated evaluations of things that need system calls etc
|
| |
|
| |
|
|
|
|
|
| |
This means we get -XHaskell98 added to the list of flags, just like we
would if we were building with Cabal.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes Trac #4875. The main point is to do dependency
analysis on type and class declarations, and kind-check them in
dependency order, so as to improve error messages.
This patch means that a few programs that would typecheck before won't
typecheck any more; but before we were (naughtily) going beyond
Haskell 98 without any language-extension flags, and Trac #4875
convinces me that doing so is a Bad Idea.
Here's an example that won't typecheck any more
data T a b = MkT (a b)
type F k = T k Maybe
If you look at T on its own you'd default 'a' to kind *->*;
and then kind-checking would fail on F.
But GHC currently accepts this program beause it looks at
the *occurrences* of T.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cygwin's /bin/install doesn't set file modes correctly if the
destination path is a C: style path:
$ /bin/install -c -m 644 foo /cygdrive/c/cygwin/home/ian/foo2
$ /bin/install -c -m 644 foo c:/cygwin/home/ian/foo3
$ ls -l foo*
-rw-r--r-- 1 ian None 0 2011-01-06 18:28 foo
-rw-r--r-- 1 ian None 0 2011-01-06 18:29 foo2
-rwxrwxrwx 1 ian None 0 2011-01-06 18:29 foo3
This causes problems for bindisttest/checkBinaries.sh which then
thinks that e.g. the userguide HTML files are binaries.
We therefore use a /cygdrive path if we are on cygwin
|
| |
|
| |
|