Source Location of DataCon objects in GHC 7.4.1 API
Hello
I have a failing test in BuildWrapper when moving from GHC 7.0.4 to
7.4.1. As far I can tell, in the TypecheckedSource I get DataCon
objects that have no location info, and hence I can't retrieve them by
location... Which is useful in a IDE (tell me what's under my mouse
cursor, tell me where else it's used).
Given the simple data declaration:
data DataT=MkData {name :: String}
In 7.0.4 I obtain a hierarchy that ends in FunBind (on a Var called
name)/MatchGroup/Match/ConPatOut and the contained DataCon named
MkData has a SrcSpan associated with it, and so do the Var,
MatchGroup and Match.
In 7.4.1 I have the same hierarchy but the DataCon tells me no
location info. The Var name has a location, but the MatchGroup and
Match don't either.
Is it a normal change? Do I need to change something in the way I load
the module? Is it a regression?
Thanks!
--
JP Moresmau
http://jpmoresmau.blogspot.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Understanding ghc-pkg dependencies when not using cabal
Hi all,
I'm very interested in distributing ghc packages via zero-install [0].
I'm excited about ghc 7.4's ${pkgroot} support, since it means that
many packages could now be made relocatable (as long as they don't
need to know about paths to resources, etc). But I'm having some
trouble understanding exactly what relationships exist between
packages and when packages are needed / used. I have a lot of
questions. Answering all of them would be wonderful, but even just
some at least would be handy too ;)
For an example, lets use ansi-terminal [1] (and assume we're building
it on a unix host)
ansi-terminal depends on `base` and `unix` packages. Do these need to
be present in source form, or just in compiled package form? I'm
assuming the latter.
(by compiled package, I mean the stuff that ends up in e.g
~/.cabal/lib/PACKAGENAME)
When I built ansi-terminal, the package.conf I got out of `cabal
register` had the following field:
depends: base-4.5.0.0-6db966b4cf8c1a91188e66d354ba065e
unix-2.5.1.0-c004d6a0692bba682bbf2ac7b61d8322
So presumably this is the exact version that was used for compilation.
Obviously the first part is the version, but what is the second part?
Is it the abi-hash of the library that was used at compile time?
If I want to use ansi-terminal in a program that I'm compiling, how
strict are these dependencies? Will a `unix` package of a different
version and the same abi-hash be acceptable? Does it need to be
strictly _newer_ than 2.5.1.0 (and still have the same abi-hash)? Or
is this an exact dependency? If I distribute the `unix` library in
compiled form, how likely is it that a given compiled version of
`unix` will satisfy the requirement?
If I have compiled two libraries that both depend on `unix`, but they
ended up referencing a different abi-hash of `unix` (maybe I compiled
them on a different computer, or on slightly different versions of the
source), what happens when I try to compile an application that
depends on these two libraries? I presume it couldn't work, even if I
had registered both versions of `unix` simultaneously (is this even
possible to do?).
Under what circumstances will the same package source code (e.g
unix-2.5.1.0) have two different abi-hashes? From [2], it sounds
like only major GHC version changes should affect it. Is the abi-hash
consistent on different platforms (assuming the same major GHC version
is used)?
Can the output of `ghc --abi-hash` (with no arguments) be used as a
linkage restriction? (i.e if I have the exact same source and two
versions of ghc with the same abi-hash, will the compiled library
necessarily end up with the same abi-hash in both cases?).
If the `unix` package releases a new version that is compatible with
ansi-terminal, what would I have to do to get this updated code into
my application (that depends on ansi-terminal)?
- install new version of `unix`, and recompile my application
- as above, but also rebuilding the current version of
`ansi-terminal` before I rebuild my application (despite ansi-terminal
not actually changing itself)
Perhaps the above question could be rephrased as if a new version of
`unix` is source-compatible with the previous, what recompilation (if
any) of downstream libraries is / could be required?
I know that ghc compiles applications statically by default. Given
this, I'm a little confused by the lifetime of packages in ghc. Are
packages (in the sense of the stuff that is listed by `ghc-pkg
list`) only required at compilation time? If I run a precompiled
program that depends on another haskell package which has been
compiled as a shared library, does this mean I need the ghc package to
be registered, or is it sufficient to just have the compiled .so on my
$LD_LIBRARY_PATH?
Apologies for the large number of questions, and thanks for your time.
- Tim.
[0]: http://0install.net/
[1]: http://hackage.haskell.org/package/ansi-terminal-0.5.5
[2]: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Packages
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding ghc-pkg dependencies when not using cabal
Hi, as I’m involved with the Debian packaging I can probably answer a few of your questions. Am Samstag, den 02.06.2012, 00:01 +1000 schrieb Tim Cuthbertson: For an example, lets use ansi-terminal [1] (and assume we're building it on a unix host) ansi-terminal depends on `base` and `unix` packages. Do these need to be present in source form, or just in compiled package form? I'm assuming the latter. (by compiled package, I mean the stuff that ends up in e.g ~/.cabal/lib/PACKAGENAME) Correct. See http://packages.debian.org/sid/amd64/libghc-ansi-terminal-dev/filelist for what Debian packages contain; that is sufficient to build libraries depending on this one. (We have separate -prof and -doc packages, though.) When I built ansi-terminal, the package.conf I got out of `cabal register` had the following field: depends: base-4.5.0.0-6db966b4cf8c1a91188e66d354ba065e unix-2.5.1.0-c004d6a0692bba682bbf2ac7b61d8322 So presumably this is the exact version that was used for compilation. Obviously the first part is the version, but what is the second part? Is it the abi-hash of the library that was used at compile time? It is a hash across everything that is being exposed by the library, so yes. If I want to use ansi-terminal in a program that I'm compiling, how strict are these dependencies? Will a `unix` package of a different version and the same abi-hash be acceptable? Does it need to be strictly _newer_ than 2.5.1.0 (and still have the same abi-hash)? Or is this an exact dependency? If I distribute the `unix` library in compiled form, how likely is it that a given compiled version of `unix` will satisfy the requirement? They are very strict, i.e. both version _and_ hash have to match. If I have compiled two libraries that both depend on `unix`, but they ended up referencing a different abi-hash of `unix` (maybe I compiled them on a different computer, or on slightly different versions of the source), what happens when I try to compile an application that depends on these two libraries? I presume it couldn't work, it can work, at least if the unix libraries they have _different_ versions and the two libraries do not try to interact using types or type classes from unix. We have had this situation with parsec-2 and parsec-3 for a while in Debian and worked ok, but should probably be avoided. even if I had registered both versions of `unix` simultaneously (is this even possible to do?). AFAIK it is not yet possible, but it is planned to make that possible. Under what circumstances will the same package source code (e.g unix-2.5.1.0) have two different abi-hashes? From [2], it sounds like only major GHC version changes should affect it. Is the abi-hash consistent on different platforms (assuming the same major GHC version is used)? Different GHC versions, different versions of depending libraries, in some cases other stuff. E.g. the abi hash of the ghc library itself varies depending on the version number of the ghc you compile ghc with. So the first build of a new ghc version has a different abi hash than the second build (if it is the first built with the new version). This causes some problems here on the Debian front. Generally assume ABI hashes to be fragile, and be happy if they don’t change. Can the output of `ghc --abi-hash` (with no arguments) be used as a linkage restriction? (i.e if I have the exact same source and two versions of ghc with the same abi-hash, will the compiled library necessarily end up with the same abi-hash in both cases?). Likely, but I suggest not to rely on it in your packaging processes. Or at least prepare to detect if it goes wrong and clean up. If the `unix` package releases a new version that is compatible with ansi-terminal, what would I have to do to get this updated code into my application (that depends on ansi-terminal)? - install new version of `unix`, and recompile my application - as above, but also rebuilding the current version of `ansi-terminal` before I rebuild my application (despite ansi-terminal not actually changing itself) The latter. Perhaps the above question could be rephrased as if a new version of `unix` is source-compatible with the previous, what recompilation (if any) of downstream libraries is / could be required? Simple: Rebuild all. Ok, not entirely true: It may happen that A depends on B and B on C, an upgrading C requires a rebuild of B but the ABI hash of B is not affected. In that case you do not have to rebuild A, but there is no way of telling in advance. I know that ghc compiles applications statically by default. Given this, I'm a little confused by the lifetime of packages in ghc. Are packages (in the sense of the stuff that is listed by `ghc-pkg list`) only required at compilation time? Yes. Haskell-based programs in Debian do not carry any haskellish dependendencies any more, e.g. http://packages.debian.org/sid/git-annex Given the fragility of
