- cabal-devel - Haskell.org

patch applied (cabal): Add a unuque identifier for installed packages (part 3 of 9)
by Duncan Coutts 22 Aug '09

22 Aug '09

Thu Aug 6 06:18:10 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * Add a unuque identifier for installed packages (part 3 of 9) Ignore-this: 455a736ea5a3241aa6040f4c684ab0b3 This part adds the InstalledPackageIndex type to Distribution.Simple.PackageIndex. Now that packages have a unique identifier within a package database, it makes sense to use this as the key for looking up installed packages, so InstalledPackageIndex is a mapping from InstalledPackageId to InstalledPackageInfo. Distribution.Simple.PackageIndex still supports other kinds of package mappings: PackageIndex is a mapping from PackageName. All the functions in the section "Special Queries" now work on InstalledPackageIndex rather than PackageFixedDeps pkg => PackageIndex pkg: topologicalOrder, reverseTopologicalOrder, dependencyInconsistencies, dependencyCycles, brokenPackages, dependencyClosure, reverseDependencyClosure dependencyGraph M ./Distribution/Simple/PackageIndex.hs -103 +146 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090806131810-12142-7676550c…

1 0

patch applied (cabal): Add a unuque identifier for installed packages (part 2 of 9)
by Duncan Coutts 22 Aug '09

22 Aug '09

Thu Aug 6 06:19:06 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * Add a unuque identifier for installed packages (part 2 of 9) Ignore-this: f3fba4465373bd4b7397384f08ca189e Note: this patch doesn't build on its own, you also need the rest of the patch series. Compatibility with older GHCs. When reading a package database created by an older version of GHC without installedPackageIds, we have to fake an InstalledPackageId for the internal InstalledPackageInfo. So, when reading in an InstalledPackageInfo from an older GHC, we set the installedPackageId to be the textual representation of the PackageIdentifier: i.e. <package>-<version>. Now, previously the depends field of InstalledPackageInfo was [PackageIdentifier], and is now [InstalledPackageId], so we will read each PackageIdentifier as an InstalledPackageId (a String). The dependencies will still point to the correct package, however, because we have chosen the installedPackageId to be the textual representation of the PackageIdentifier. M ./Distribution/Simple/GHC/IPI641.hs -1 +7 M ./Distribution/Simple/GHC/IPI642.hs -2 +6 M ./Distribution/Simple/Program/HcPkg.hs -3 +20 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090806131906-12142-e3ff1a46…

1 0

patch applied (cabal): Add a unuque identifier for installed packages (part 1 of 9)
by Duncan Coutts 22 Aug '09

22 Aug '09

Thu Aug 6 06:19:28 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * Add a unuque identifier for installed packages (part 1 of 9) Ignore-this: b774e5719e666baee504e1f52381cc8b NOTE: the patch has been split into 9 pieces for easy reviewing, the individual pieces won't build on their own. Part 1 does the following: Distribution.Package: - define the InstalledPackageId type as a newtype of String Distribution.InstalledPackageInfo: - add an installedPackageId field to InstalledPackageInfo - change the type of the depends field from [PackageIdentifier] to [InstalledPackageId] The idea behind this change is to add a way to uniquely identify installed packages, letting us decouple the identity of an installed package instance from its package name and version. The benefits of this are - We get to detect when a package is broken because its dependencies have been recompiled, or because it is being used with a different package than it was compiled against. - We have the possibility of having multiple instances of a given <package>-<version> installed at the same time. In the future this might be used for "ways". It might also be useful during the process of upgrading/recompiling packages. M ./Distribution/InstalledPackageInfo.hs -11 +10 M ./Distribution/Package.hs -3 +24 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090806131928-12142-5ef3fc82…

1 0

patch applied (cabal): Refactoring: fit into 80 columns
by Duncan Coutts 22 Aug '09

22 Aug '09

Thu Aug 6 04:58:25 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * Refactoring: fit into 80 columns Ignore-this: e4e9bdea632814842121fcf7c7d6c3a M ./Distribution/Simple/Configure.hs -5 +12 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090806115825-12142-d43d067e…

1 0

[Hackage] #575: Cabal configure leaves behind temporary files on Windows
by Hackage 19 Aug '09

19 Aug '09

#575: Cabal configure leaves behind temporary files on Windows ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.10.1 Platform: Windows | ----------------------------------+----------------------------------------- Every time 'configure' is run on Windows, a single .exe is left behind in the user's %TEMP% directory and is never removed. The problem is in checkForeignDeps in Distribution.Simple.Configure, specifically when GCC is run in builds. A temporary filename is created to hold the output, but it has no extension. When GCC is given this filename for output it appends .exe extension automatically. Since this is a different filename it never gets removed. Fix is to specify an extension for the output, like ".tmp", so GCC will actually put it there. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/575> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Changelogs and "available since"
by Laszlo Nagy 18 Aug '09

18 Aug '09

Hi All, I was volunteer to solve this problem: <http://hackage.haskell.org/trac/summer-of-code/ticket/1565> In a conversation on the libraries(a)haskell.org I was suggested to scratch my idea here. I would use hoogle for this. Currently it stores the package name and the symbols of the modules about a package. I would extend it to store the version of the package as well. Extend the query methods to use all the available package description at search. And make a VersionRange from the matched Versions. In a second turn I have to solve the problem, how a user can get all the hoogle files about every version of the used packages. (Applied version policy can help to have less files.) #1 Using a central repository, (like hackage) where upload require hoogle input file as well. #2 Implement a tool, top of (or inside) cabal-install, which generates all the needed files. Finally Haddock has to be taught to query hoogle to get availability description for each symbol. Please feel free to suggest other ideas or tell your opinion about mine. Regards, Laszlo

4 3

darcs patch: Add --html for haddock command.
by Thomas Schilling 16 Aug '09

16 Aug '09

Sun Aug 16 02:40:17 BST 2009 Thomas Schilling <nominolo(a)googlemail.com> * Add --html for haddock command. This makes it easier to build both html documentation and a hoogle database: ./setup haddock [--html] # build only HTML docs (default) ./setup haddock --hoogle # build only Hoogle DB ./setup haddock --hoogle --html # build both

1 0

[Hackage] #467: Add support for HPC profiling.
by Hackage 15 Aug '09

15 Aug '09

#467: Add support for HPC profiling. ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Similar to how we support ghc's "normal" profiling way, we should enable support to build packages with hpc turned on. This would also eliminate the need for people to add support on a per- package basis, see eg #430. See also #200. We should consider how to support these various flavours of profiling in a more extensible way. Different compilers have different ways, for example nhc has several (especially when used with hat). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/467> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

patch applied (cabal): Use a simpler method for the check on the base-upper-bound
by Duncan Coutts 12 Aug '09

12 Aug '09

Wed Aug 12 06:33:13 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Use a simpler method for the check on the base-upper-bound Ignore-this: 9234cc76670a135906c8b7d2e19e6199 The key point is that we do not complain for packages that do not depend on base at all (like ghc-prim). M ./Distribution/PackageDescription/Check.hs -13 +13 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090812133313-adfee-c76d97f6…

1 0

Re: patch applied (packages/Cabal): Fix the base-upper-bound Cabal check error
by Duncan Coutts 12 Aug '09

12 Aug '09

On Tue, 2009-08-11 at 15:34 -0700, Ian Lynagh wrote: > Tue Aug 11 13:44:55 PDT 2009 Ian Lynagh <igloo(a)earth.li> > * Fix the base-upper-bound Cabal check error > > M ./Distribution/PackageDescription/Check.hs -7 +11 This should be pushed to the Cabal HEAD repo before going into ghc's Cabal branch. Duncan

2 1