- cabal-devel - Haskell.org

Re: [Hackage] #128: cabal building broken libraries when module list is not complete
by Hackage 25 Jun '08

25 Jun '08

#128: cabal building broken libraries when module list is not complete ----------------------------------+----------------------------------------- Reporter: m(a)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 duncan): To be honest I'd much rather spend time working on a proper solution than on intermediate hacky solutions like reading the output of `ghc -v2`. If someone else wants to implement that then fine I'm not totally against it but I don't really see it as a good use of our limited development time. The module/file dependency chasing is scheduled to be done by the end of the summer however that project only aims to make a prototype and demonstrate it on the case of pre-processors. I expect that it will take a bit longer before we are able to use it to replace the use of `ghc --make`. As for ticket #159, it's one of two existing prototypes for the make-style dependency problem. The GSoC project is pursuing a slightly different approach. I don't think package dependency resolution is the same problem as file/module dependency chasing despite initial similarities. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/128#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #128: cabal building broken libraries when module list is not complete
by Hackage 25 Jun '08

25 Jun '08

#128: cabal building broken libraries when module list is not complete ----------------------------------+----------------------------------------- Reporter: m(a)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:6 claus]: > Replying to [comment:5 duncan]: > > Sure it's a bug but it's a bug that depends on a huge new feature. > > 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. > Btw, even while you're using the compiler's dependency chasing, doesn't that tell you which modules it finds and uses (GHC does)? simply adding `-v2` to `build` should give dependency info to `stdout`, among other info, eg, for some mini-dummy package `p` that only imports its own `Paths_p` we get: {{{ $ runhaskell.exe Setup.hs build -v --ghc-options="-v2" Creating dist\build (and its parents) Creating dist\build\autogen (and its parents) Preprocessing library p-0... Building p-0... Building library... Creating dist\build (and its parents) c:\ghc\ghc-6.9.20080514\bin\ghc.exe -v2 -package-name p-0 --make -hide- all-packages -i -idist\build -i. -idist\build\autogen -Idist\build -odir dist\build -hidir dist\build -stubdir dist\build -packag e base-3.0 -O P Paths_p Glasgow Haskell Compiler, Version 6.9.20080514, for Haskell 98, stage 2 booted by GHC version 6.6.1 Using package config file: C:\ghc\ghc-6.9.20080514\package.conf wired-in package ghc-prim mapped to ghc-prim-0.1 wired-in package integer mapped to integer-0.1 wired-in package base mapped to base-3.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1 wired-in package template-haskell mapped to template-haskell-2.2 wired-in package ndp not found. *** Chasing dependencies: Chasing modules from: P.hs,Paths_p Stable obj: [P, Paths_p] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Wed Jun 25 15:05:33 GMT Daylight Time 2008 ms_mod = p-0:Paths_p, ms_imps = [System.Environment, Data.Version] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Tue Jun 24 15:00:42 GMT Daylight Time 2008 ms_mod = p-0:P, ms_imps = [Paths_p] ms_srcimps = [] }] }}} The `ms_imps` in the `ModSummary`s seem to give the basic dependency info you're looking for. There's also a `--include-pkg-deps` option, but I can't figure out how to make that make a difference: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate- compilation.html#makefile-dependencies -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/128#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #128: cabal building broken libraries when module list is not complete
by Hackage 25 Jun '08

25 Jun '08

#128: cabal building broken libraries when module list is not complete ----------------------------------+----------------------------------------- Reporter: m(a)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

1 0

Re: [Hackage] #128: cabal building broken libraries when module list is not complete
by Hackage 24 Jun '08

24 Jun '08

#128: cabal building broken libraries when module list is not complete ----------------------------------+----------------------------------------- Reporter: m(a)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: ----------------------------------+----------------------------------------- Changes (by duncan): * type: enhancement => defect Comment: Sure it's a bug but it's a bug that depends on a huge new feature. 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. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/128#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #128: cabal building broken libraries when module list is not complete
by Hackage 24 Jun '08

24 Jun '08

#128: cabal building broken libraries when module list is not complete ----------------------------------+----------------------------------------- Reporter: m(a)tel.netbeisser.de | Owner: Type: enhancement | 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: ----------------------------------+----------------------------------------- Changes (by claus): * cc: claus (added) Comment: installing broken libraries is no good at all - compare #306 for the version I ran into. looks like a bug to me, even if it needs more infrastructure before it can be fixed properly. in the mean time, is there no way to have cabal make a test install before packaging/upload, to make sure that the package is at least complete, builds, and loads (ie., using some compiler's dependency chasing to raise errors before distribution/installation)? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/128#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-install): Fix for when user supplies incorrect upload username/passwd
by Duncan Coutts 24 Jun '08

24 Jun '08

Mon Jun 23 04:33:15 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix for when user supplies incorrect upload username/passwd Should now return a proper error rather than an internal error from the HTTP library. M ./Hackage/Upload.hs -3 +5 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080623113315-adfee-…

1 0

[Hackage] #305: Link to Cabal 1.2.3.0 is dead
by Hackage 24 Jun '08

24 Jun '08

#305: Link to Cabal 1.2.3.0 is dead ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.2.2 Platform: | ----------------------------------+----------------------------------------- The link on http://haskell.org/cabal/download.html to version 1.2.3.0 is dead, it should be http://haskell.org/cabal/release/cabal-1.2.3.0/cabal-1.2.3.0.tar.gz -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/305> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #258: case confusion - cabal vs Cabal
by Hackage 23 Jun '08

23 Jun '08

#258: case confusion - cabal vs Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The darcs repo for Cabal is at darcs.haskell.org:/home/darcs/cabal yet it contains a file Cabal.cabal, which indeed claims that the name of the package is Cabal. This confusion of letter case is causing problems for me. Can we agree that Cabal is capitalised, and rename the repo dir? That seems like the simplest way to achieve consistency. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/258> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #265: Cabal field stability not useful
by Hackage 22 Jun '08

22 Jun '08

#265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- As it stands, the 'stability:' field isn't very useful. Hardly anyone uses it, and even if someone does, it does minimal good, since it's just an arbitrary string. I propose it be changed into an enumerated type, like license: is. That way we could do things like have cabal-install warn when installing unstable, add view filters to Hackage, and so on. This is all stuff that'd be pretty ad-hoc if done on whatever strings package authors were writing. Now, what should the entries be? Ideally, we'd like to be able to say a couple things. We'd like to say that a release is Stable, or Unstable. For example, HaXml's most recent package on Hackage is Unstable, and that's why Goerzen's Hpodder uses an older, Stable, version of HaXml. But we'd also like to express not just stability, but feature-completeness - Alpha, Beta, Release. It's perfectly sensible to have a piece of software which is a Stable Alpha; early XMonads were very stable (I was using it from the first public repo patches, and it only ever crashed a handful of times, less than StumpWM). And equally I'd suggest you could have Unstable Betas. Most cabal files I've seen using stability: seem to use 'Stable', 'Unstable', 'Experimental', 'Alpha', or 'Beta'. (Although GTK2HS seems to be using 'Stability: provisional'). So perhaps one could make the stability field accept 0-2 entries: one from Stable/Unstable, and one from Experimental/Alpha/Beta/Release. -- gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/265> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

Re: [Hackage] #137: setup sdist places implementation-dependent preprocessor output in the source bundle
by Hackage 20 Jun '08

20 Jun '08

#137: setup sdist places implementation-dependent preprocessor output in the source bundle ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.6 Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------------+----------------------------------------- Comment (by igloo): Incidentally, `include/HsGLUT.h` is in `extra-tmp-files`; should Cabal look at that when deciding what to put in the sdist? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/137#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0