March 2011 - cabal-devel

[Hackage] #825: Documentation about auto generated version constant (patch included)
by Hackage 18 Apr '11

18 Apr '11

#825: Documentation about auto generated version constant (patch included) ----------------------------------+----------------------------------------- Reporter: basvandijk | Owner: Type: task | Status: new Priority: normal | Milestone: Component: User guide | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- I needed to access the package version from package code but did not know how. Antoine Latter [comment:1:ticket:823 mentioned] it is already supported but not yet documented. The attached patch adds some minimal documentation to the user-guide. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/825> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #827: Allow Cabal to be build on GHC-6.8 (patch included)
by Hackage 18 Apr '11

18 Apr '11

#827: Allow Cabal to be build on GHC-6.8 (patch included) ----------------------------------+----------------------------------------- Reporter: basvandijk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- The attached patch allows Cabal to be build on GHC-6.8 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/827> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Overhaul Cabal's testsuite
by Frank Murphy 01 Apr '11

01 Apr '11

What do people think about seeing this ticket (#212) resolved as part of a SoC project? Is it worthwhile enough to merit consideration? Frank

4 6

Re: [Hackage] #212: Overhaul Cabal's testsuite
by Hackage 31 Mar '11

31 Mar '11

#212: Overhaul Cabal's testsuite ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very hard (<1 week) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Comment(by tibbe): Perhaps we could use the new test suite functionality for (some of) the tests? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/212#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Plan of Attack for Parallel Builds
by Frank Murphy 30 Mar '11

30 Mar '11

I've been looking around and trying to develop a plan for parallelizing builds in cabal-install. Here's my idea so far: - Parallelize executeInstallPlan. When given a target load average as a flag it will determine whether it should spawn a worker (if below the target load average) or wait. If waiting, it will listen to all worker status channels and print out their current build status and the load average. Once a worker exits, it will again check the load average and spawn a new thread if necessary. - Rewrite install.*Package and their callees to use the CHP (Communicating Haskell Process) monad where possible. Use channels to communicate build status back to the main thread. - It might be necessary to parse the output of external builds in some way so that meaningful status can be communicated back to the user. - Add a default parallel build log path template. Allow the user to specify one on the command line to override the default. All output of parallel package builds will be logged in the background silently instead of displayed to the user. - On single-threaded (sequential) builds, revert to the old output style. On multi-threaded builds, display the current status of all running builds, load averages and nothing else. Possible output: Resolving dependencies... Building derive-2.3.0.2... [17 of 58] Building regex-base-0.93.1... [1 of 4] Building dyre-0.8.6... [5 of 7] Configuring xdg-basedir-0.2... [in progress] Dependencies Built: [0 of 9] Load Average: [3.4/4.0] Running 4 Jobs. A possible error message might look like: derive-2.3.0.2 failed during the building phase. Log stored in /home/frank/cabal/logs/build/derive-2.3.0.2.log What does everyone think? Thanks, Frank

6 6

Re: [Hackage] #446: Can't set path to tools in ~/.cabal/config
by Hackage 29 Mar '11

29 Mar '11

#446: Can't set path to tools in ~/.cabal/config ---------------------------------+------------------------------------------ Reporter: awick | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.10 Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): This would be particularly useful for negating the new ghc default that `-rtsopts` is needed to do any profiling or tracing. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/446#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #823: Accessing the package version from within the package
by Hackage 28 Mar '11

28 Mar '11

#823: Accessing the package version from within the package ----------------------------+----------------------------------------------- Reporter: basvandijk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Just like you can [http://haskell.org/cabal/release/cabal-latest/doc /users-guide/authors.html#paths-module access data files from a package], it would be useful to retrieve the current version of your package from within your program. This is useful when you want to print the current version of your program when the user issues a `--version` flag for example. More specifically I would like the following module to be generated automatically: {{{ module Version_pkgname where import Distribution.Version (Version) version :: Version version = <the current package version> }}} where [http://haskell.org/cabal/release/cabal-latest/doc/API/Cabal /Distribution-Version.html#t%3AVersion Version] is from the `Cabal` library. Having just a `String` for the version type is also OK and maybe even preferable because otherwise a dependency on the `Cabal` library is required. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/823> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

Re: [Hackage] #656: Cabal-1.8-style dependencies stop Haddock from working
by Hackage 25 Mar '11

25 Mar '11

#656: Cabal-1.8-style dependencies stop Haddock from working ------------------------------+--------------------------------------------- Reporter: Ivan Miljenovic | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ------------------------------+--------------------------------------------- Changes (by jeffwheeler): * cc: jeff@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/656#comment:12> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #179: support GHC's main-is extension
by Hackage 23 Mar '11

23 Mar '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by Evi1M4chine): Replying to [comment:15 cjs]: > That's pretty lame; It’s as if they had never heard of ''conditional execution''. XD -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:16> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #179: support GHC's main-is extension
by Hackage 23 Mar '11

23 Mar '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by cjs): Replying to [comment:13 duncan]: > The reason we do not support `-main-is` is because it is a ghc-specific extension that does not work for other Haskell implementations. That's pretty lame; many people write a lot of other code that works only under ghc for many other reasons. Why not just supposed ghc-specific extensions and let the build fail gracefully if someone's not using ghc? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:15> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0