increase error message detail for module lookups failure due to hi references
Consider the following build log. In particular note that we start by cleaning any local build files (rm dist).
Additionally, the user reports that transformers
is not installed and ghc-pkg check
reports no problems.
00:14:25 | morn@twi:~/dev/darcs/fastconvert -> rm -rf dist
00:14:27 | morn@twi:~/dev/darcs/fastconvert -> cabal configure -v
[...]
Dependency attoparsec ==0.8.1.1: using attoparsec-0.8.1.1
Dependency base ==4.2.0.0: using base-4.2.0.0
Dependency bytestring ==0.9.1.5: using bytestring-0.9.1.5
Dependency cmdlib ==0.3: using cmdlib-0.3
Dependency containers ==0.3.0.0: using containers-0.3.0.0
Dependency darcs ==2.5: using darcs-2.5
Dependency datetime ==0.2: using datetime-0.2
Dependency directory ==1.0.1.0: using directory-1.0.1.0
Dependency filepath ==1.1.0.3: using filepath-1.1.0.3
Dependency hashed-storage ==0.5.4: using hashed-storage-0.5.4
Dependency mtl ==1.1.1.0: using mtl-1.1.1.0
Dependency old-time ==1.0.0.3: using old-time-1.0.0.3
Dependency utf8-string ==0.3.6: using utf8-string-0.3.6
Using Cabal-1.8.0.2 compiled by ghc-6.12
Using compiler: ghc-6.12.1
[...]
00:14:31 | morn@twi:~/dev/darcs/fastconvert -> cabal build -v
[...]
/usr/bin/ghc --make -o dist/build/darcs-fastconvert/darcs-fastconvert -hide-all-packages -fbuilding-cabal-package -package-conf dist/package.conf.inplace -i -idist/build/darcs-fastconvert/darcs-fastconvert-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/darcs-fastconvert/darcs-fastconvert-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -hidir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -stubdir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -package-id attoparsec-0.8.1.1-280af3ab9743111575ea0031e8a83455 -package-id base-4.2.0.0-73995e854f236dc2acd577d7c791221d -package-id bytestring-0.9.1.5-2d4a9d624c3be86b70c04730e5f12aca -package-id cmdlib-0.3-3ef785632945f8811c8ebbd1d2e9345b -package-id containers-0.3.0.0-409fe3b8f0dda25b98e03716d26be411 -package-id darcs-2.5-47653bbe1982b022915b3fa65161767f -package-id datetime-0.2-6f38d66fddaaa0ccccffea38d6fe8d60 -package-id directory-1.0.1.0-10fc46e61b67ff4a83f3e553454d003c -package-id filepath-1.1.0.3-07812de93a673f50011d47451bcaac87 -package-id hashed-storage-0.5.4-8a6b02d90d8e1d05f233c1e31eb4a367 -package-id mtl-1.1.1.0-7772b7b72936d947193a773ada65461a -package-id old-time-1.0.0.3-b53830b41b1085071f61ca7772f44e0c -package-id utf8-string-0.3.6-a7e240d06fa0c09cfff1a5445b521d24 -O -Wall -fno-warn-unused-do-bind ./main.hs
[1 of 5] Compiling Utils ( Utils.hs, dist/build/darcs-fastconvert/darcs-fastconvert-tmp/Utils.o )
[...]
[3 of 5] Compiling Import ( Import.hs, dist/build/darcs-fastconvert/darcs-fastconvert-tmp/Import.o )
Failed to load interface for `Control.Monad.Trans.Error':
no package matching `transformers-0.2.2.0' was found
The message
Failed to load interface for `Control.Monad.Trans.Error':
no package matching `transformers-0.2.2.0' was found
appears to be due to a .hi file from one of the dependencies of the current compilation. This hi file references a module from the transformers package.
- it is hard for a user to know what is causing this module to be looked up (ie that it is a .hi file)
- it is almost impossible to work out which existing registered package contains a .hi file that refers to the non-existent
transformers
package.
If the error message specified that it was a .hi file that caused the lookup and gave e.g. the file name (or package+ver+module) of the .hi file that caused the lookup of transformers
then this would make it much easier for the user to work out what is going on and which registered package is at fault: e.g.
Failed to load interface for `Control.Monad.Trans.Error':
the package `transformers-0.2.2.0' was found
referenced by `Data.Foo` from `foo-1.0`.
Clearly there is a deeper problem here, that a registered package is out-of-sync with its registration information: the .hi refers to a package that is not mentioned in the package registration.
One way this could happen is due to inplace registrations, since it is easy in that case to rebuild the inplace .hi files without also re-registering. It may be sensible to rethink how Cabal does inplace registrations to prevent it getting out of sync.
We may also wish to have a ghc-pkg register/update/check mode that reads the .hi files and verifies them against the package registration info.
Trac metadata
Trac field | Value |
---|---|
Version | 6.12.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |