[Hackage] #128: cabal building broken libraries when module
list is not complete
Hackage
trac at galois.com
Wed Jun 25 03:46:50 EDT 2008
#128: cabal building broken libraries when module list is not complete
----------------------------------+-----------------------------------------
Reporter: m at tel.netbeisser.de | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Cabal-2.0
Component: Cabal library | Version: 1.1.6
Severity: major | Resolution:
Keywords: | Difficulty: normal
Ghcversion: 6.6 | Platform:
----------------------------------+-----------------------------------------
Comment (by claus):
Replying to [comment:5 duncan]:
> Sure it's a bug but it's a bug that depends on a huge new feature.
Is Cabal dependency chasing scheduled to be available after the summer?
Actually, it is a bit confusing that there are two separate "dependency
chasing" issues floating around (between packages and inside packages; why
not have one chaser, then extract either packages or modules?). This
ticket seems to be blocked on #15, but #159 claimed to have implemented
that 9 months ago?
> The problem is exactly that we're using the compiler's dependency
chasing. It can find modules that we did not know about which makes it
work at build time but then we miss things in the link phase.
Which is why I asked for "test installs", ie, temporarily install package,
then change to tmp dir and try to load installed package. If that fails,
there was an unrecorded local dependency and, to some extent, vice-versa.
Of course, that would depend on a working "uninstall" command (#106,
#234)..
Btw, even while you're using the compiler's dependency chasing, doesn't
that tell you which modules it finds and uses (GHC does)?
--
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/128#comment:6>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects
More information about the cabal-devel
mailing list