- cabal-devel - Haskell.org

Re: [Hackage] #227: cabal-install doesn't consider build-tools as dependencies
by Hackage 02 Apr '11

02 Apr '11

#227: cabal-install doesn't consider build-tools as dependencies ---------------------------------+------------------------------------------ Reporter: guest | Owner: duncan Type: defect | Status: assigned Priority: normal | Milestone: cabal-install-0.8 Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: dependencies build tools Difficulty: hard (< 1 day) | Ghcversion: 6.12.3 Platform: | ---------------------------------+------------------------------------------ Changes (by mcandre): * keywords: => dependencies build tools * ghcversion: 6.8.2 => 6.12.3 Comment: I have the same problem with ncurses and c2hs. I'd really like dependencies to be handled automatically whenever possible. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/227#comment:11> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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 24 Mar '11

24 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 24 Mar '11

24 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

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:13 duncan]: > The file name does not need to be Main.hs, it can be any name.hs that you like. Correct. > The reason we do not support `-main-is` is because it is a ghc-specific extension that does not work for other Haskell implementations. You already said that. I explained why this is a moot point. So actually this can be replaced with "". :) > Your example is easy to deal with. If you want one module with two targets, define both targets in one module, then have two other 2-line .hs files to be the main modules, e.g.: Aand that’s ''exactly'' what I meant with the pointless “mess”. :) Ok, I’ll simply not use cabal, and be done with it. It’s not even worth forking it, since Portage already does everything I don’t want to do myself. I know, I don’t pay money and don’t have a contract, so I can not make and demands anyway. But: FAIL. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:14> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0