#1372: Recompilation checker should consider package versions (and other
factors)
-------------------------+--------------------------------------------------
Reporter: bringert | Owner:
Type: bug | Status: new
Priority: high | Milestone: 6.8
Component: Compiler | Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
-------------------------+--------------------------------------------------
Comment (by simonmar):
Distilled conversation with Simon PJ this morning, concerning how to
detect when dependent packages have "changed" in order to force
recompilation.
First, we'll store a timestamp with each package in the database, being
the time at which the package was registered (or perhaps, built). This
timestamp will be recorded with each dependent package in the .hi file.
We can now tell when a package that we depend on has been re-registered,
which will catch cases where you recompile a Cabal package, install it,
and then continue building another package.
We also want to notice when:
* a new version of a package has been installed. The old one may have
been
either left in place or removed.
* You're using -hide-all-packages, and the package flags have changed,
meaning
that modules you import now resolve differently. This happens when you
re-configure a Cabal package after installing new packages, and build
without
cleaning first.
* You're using --make, the exposed packages have changed, meaning that
modules you import now resolve differently. This happens when not
using
Cabal.
All these cases are covered by "imported modules now resolve differently",
so for each module we compile we'll check that condition. We know the
imported modules: they're in the `ModSummary` (for one-shot compilation
we'll have to generate a `ModSummary`, for make-mode we already have it
from the downsweep).
For each directly imported module, resolve it using `findModule` (the
`ModSummary` could record the results of that, since the downsweep already
needs to do it). If the resulting module or package is not in the
dependencies listed in the .hi file, or the resolution is ambiguous, then
we recompile.
This will not catch some very obscure and highly unlikely cases, such as
when a module moves from one package to another package, and the package
timestamps haven't changed.
This will also not catch the case when a package is registered in-place
using Cabal, it is rebuilt, but not re-registered. The timestamp won't be
updated, but the package has changed, and things will go wrong. To handle
this case we'd have to track module versions across package boundaries,
which is something we definitely don't want to do: one advantage of
package boundaries is that you can avoid doing fine-grained dependency
tracking across them.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1372>
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
