#1372: Recompilation checker should consider package versions (and other
factors)
----------------------+-----------------------------------------------------
Reporter: bringert | Owner: simonmar
Type: bug | Status: new
Priority: normal | Milestone: 6.8 branch
Component: Compiler | Version: 6.8.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
----------------------+-----------------------------------------------------
Comment (by dons):
Replying to [comment:20 simonmar]:
> Please could you describe exactly the sequence of events that leads to
the crash?
>
> To be clear: I believe all compile-time errors can be avoided by bumping
versions when APIs change. If you have evidence to the contrary, I need
to hear about it.
Yes, the situation is improving. We bump most libraries now, cabal is
spotting changes to .cabal files. Cabal is spotting .cabal file changes in
particular, which is great.
The current xmonad architecture, where xmonad's core is a library (much
like ghc-api) is creating more troubles. User extensions are in a library
that depends on the xmonad library. When xmonad changes, which it does
fairly often, the XMonadContrib library users don't remember to clean,
they sometimes get linker errors or segfaults (see this bug report
http://code.google.com/p/xmonad/issues/detail?id=93&can=1 for example).
This I think is the only case currently where we have link problems: no
.cabal version change, one library changes and is reinstalled, the library
that uses it doesn't see the package.conf file changed, isn't cleaned
first, builds, then won't link (or it does, and crashes).
Could cabal just require a clean whenever the package.conf changes? (Or
does it do that already, and we need to point users to a newer cabal
version)?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1372#comment:21>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
