On Tue, 2008-08-26 at 15:53 +0100, Claus Reinke wrote:
GHC knows what the problem is but it's just following orders. Cabal gave the orders but doesn't know there is a problem.
Since you said "don't hold your breath for Cabal's dependencies": Cabal doesn't have to pass on ghc's messages uninterpreted. That's a lot like implementing a map as a list and complaining about empty list instead of element not found.
I see what you're saying, but in practise it's just not possible. GHC can return a non-zero exit code for a multitude of reasons (most of which will be genuine errors in your source code). It's just not practical to parse the error messages that ghc produces and try and reinterpret them. I fear it'd quite easy to introduce more problems than are solved this way. If one wanted to take this approach you'd need to have some mode where error messages are produced in a machine readable format (which is of course doable if you write a client using the ghc api). A quicker hack would be to change ghcs error message in this circumstance, where the -hide-all-packages flag is given. Given our limited amount of volunteer developer time I think it's much better investing it in proper solutions. Duncan