June 2008 - cabal-devel

patch applied (cabal): Add ModuleName as a new type instead of using String everywhere
by Duncan Coutts 26 Jun '08

26 Jun '08

Thu Jun 26 12:29:39 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add ModuleName as a new type instead of using String everywhere M ./Cabal.cabal +1 M ./Distribution/InstalledPackageInfo.hs -3 +5 A ./Distribution/ModuleName.hs M ./Distribution/PackageDescription.hs -4 +5 M ./Distribution/PackageDescription/Check.hs -2 +2 M ./Distribution/PackageDescription/Parse.hs -2 +2 M ./Distribution/ParseUtils.hs -7 +4 M ./Distribution/Simple/Build.hs -3 +4 M ./Distribution/Simple/BuildPaths.hs -2 +4 M ./Distribution/Simple/GHC.hs -7 +8 M ./Distribution/Simple/GHC/IPI642.hs -2 +4 M ./Distribution/Simple/Haddock.hs -12 +15 M ./Distribution/Simple/Hugs.hs -8 +15 M ./Distribution/Simple/JHC.hs -2 +3 M ./Distribution/Simple/NHC.hs -5 +7 M ./Distribution/Simple/PreProcess.hs -8 +14 M ./Distribution/Simple/SrcDist.hs -6 +9 M ./Distribution/Simple/Utils.hs -11 +6 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080626192939-adfee-c9edc16a…

1 0

patch applied (cabal): Tweaks to the readme, hopefully will reduce confusion
by Duncan Coutts 26 Jun '08

26 Jun '08

Wed Jun 25 16:20:51 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Tweaks to the readme, hopefully will reduce confusion M ./README -2 +10 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080625232051-adfee-27cc376b…

1 0

patch applied (cabal): Add compat InstalledPackageInfo types for older GHCs
by Duncan Coutts 26 Jun '08

26 Jun '08

Fri Jun 20 18:37:27 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add compat InstalledPackageInfo types for older GHCs We need these types for their Read instances so that we can still read older GHCs package db files when we make changes to the current InstalledPackageInfo type, or the types contained in it, like PackageIdentifier or License. M ./Cabal.cabal +2 M ./Distribution/Simple/GHC.hs -4 +21 A ./Distribution/Simple/GHC/IPI641.hs A ./Distribution/Simple/GHC/IPI642.hs M ./Makefile -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080621013727-adfee-9c0bab6b…

1 0

patch applied (cabal): Add simple file name globbing (*) to data-files and extra-source-files
by Duncan Coutts 26 Jun '08

26 Jun '08

Thu Jun 26 10:14:24 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add simple file name globbing (*) to data-files and extra-source-files M ./Distribution/Simple/Install.hs -4 +6 M ./Distribution/Simple/SrcDist.hs -5 +8 M ./Distribution/Simple/Utils.hs -2 +33 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080626171424-adfee-cf1dd1d8…

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 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