April 2009 - cabal-devel

[Hackage] #427: how to access temporary build-files/logs?
by Hackage 22 Dec '09

22 Dec '09

#427: how to access temporary build-files/logs? ----------------------------+----------------------------------------------- Reporter: claus | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- when trying to debug an installation failure, it would be most useful to be able to keep the temporary build files (similar to ghc's -keep* options). Apart from being able to look at things like `config.log`, it would also allow to experiment with patched commands from the verbose build log (which needs the temporary files still present). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/427> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #216: need a way to specify the foreign libraries a package depends on
by Hackage 22 Dec '09

22 Dec '09

#216: need a way to specify the foreign libraries a package depends on ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: major | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------------+----------------------------------------- Package descriptions allow one to specify which Haskell libraries a package depends on, but foreign ones. Designing something that can be used with native package managers is complicated because many of them alter the upstream library names in unpredictable ways. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/216> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #545: Uninformative error message when cabal-install fails on WinXP
by Hackage 22 Dec '09

22 Dec '09

#545: Uninformative error message when cabal-install fails on WinXP ---------------------------------+------------------------------------------ Reporter: abayley | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ "cabal install binary" fails on my WinXP machine with this error: Resolving dependencies... Downloading binary-0.4.4... cabal: Error: some packages failed to install: binary-0.4.4 failed while downloading the package. Suspect it's related to proxy configuration, but the error message could be more informative. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/545> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #542: installing cabal-install refers to editing nonexistent file $HOME/.cabal/config
by Hackage 22 Dec '09

22 Dec '09

#542: installing cabal-install refers to editing nonexistent file $HOME/.cabal/config ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ {{{cabal --help}}} invites me to edit a file that doesn't exist, and I can't easily find documentation for the file: {{{ : nr@homedog 5520 ; cabal --help This program is the command line interface to the Haskell Cabal infrastructure. ... You can edit the cabal configuration file to set defaults: /home/nr/.cabal/config : nr@homedog 5521 ; ls -l /home/nr/.cabal/config ls: cannot access /home/nr/.cabal/config: No such file or directory }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/542> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #529: sdist creation code currently doesn't work with Solaris's tar
by Hackage 22 Dec '09

22 Dec '09

#529: sdist creation code currently doesn't work with Solaris's tar ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Cabal's sdist creation code currently doesn't work on Solaris. The code (in Cabal's Distribution/Simple/SrcDist.hs) is: {{{ let tarBallFilePath = targetPref </> tarBallName pkg_descr <.> "tar.gz" rawSystemProgram verbosity tarProg ["-C", tmpDir, "-czf", tarBallFilePath, tarBallName pkg_descr] return tarBallFilePath }}} but it looks like we need this instead: {{{ let tarFilePath = targetPref </> tarBallName pkg_descr <.> "tar" tarBallFilePath = tarFilePath <.> "gz" rawSystemProgram verbosity tarProg ["-cf", tarFilePath, "-C", tmpDir, tarBallName pkg_descr] rawSystemProgram verbosity gzipProg [tarFilePath] removeFile tarFilePath return tarBallFilePath }}} Note that we don't actually tell gzip where to put the output, but I can't see a way to do so without messing with stdout. See http://hackage.haskell.org/trac/ghc/ticket/3106 for more details on the problems. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/529> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #372: cabal sdist --snapshot does not work, while ./setup sdist snapshot does
by Hackage 22 Dec '09

22 Dec '09

#372: cabal sdist --snapshot does not work, while ./setup sdist snapshot does ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ Hi, cabal sdist has a bug, which does not appear when using Setup.lhs {{{ $ cabal clean cleaning... $ cabal sdist --snapshot Warning: Cannot run preprocessors. Run 'configure' command first. Building source dist for free-theorems-0.2.1.20081016... cabal: dist/src/free-theorems-0.2.1: getDirectoryContents: does not exist (No such file or directory) $ runhaskell Setup.lhs sdist --snapshot Warning: Cannot run preprocessors. Run 'configure' command first. Building source dist for free-theorems-0.2.1.20081016... Source tarball created: dist/free-theorems-0.2.1.20081016.tar.gz $ cat Setup.lhs #!/usr/bin/env runhaskell > import Distribution.Simple > main = defaultMain }}} Using cabal-install 0.6.0, Cabal 1.6.0.1, ghc 6.8.2. I haven’t looked at the code, but I assume it’s a simple mistake. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/372> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #299: Add changelog feature to hackagedb
by Hackage 22 Dec '09

22 Dec '09

#299: Add changelog feature to hackagedb --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- It would be great if releases on hackagedb were required (or even permitted) to include short descriptions of the changes made since the last release. Currently there is no easy way to get this information for most packages, since many packages have no home page other than their hackagedb page. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/299> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 10

[Hackage] #478: allow comments on any line, don't require '.' for blank lines
by Hackage 20 Dec '09

20 Dec '09

#478: allow comments on any line, don't require '.' for blank lines ----------------------------+----------------------------------------------- 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: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It confuses people that in `.cabal` files, comments can only appear on lines on their own, and not at the end of other lines. We should consider relaxing this as long as it can be done in a backwards compatible way. The only thing to worry about is command line flags like: {{{ cc-options: --some-flag }}} If we required a space after the `--` that might be sufficient. There are some tools that interpret `--` on its own as an argument, but usually only as a separator between flag arguments and non-flag arguments and we do not expect those to be given in .cabal files. We might like to allow `--` within quotes eg `"--"` however that's also not easy because of the syntax and format of .cabal files. They have no consistent lexical syntax, each field is parsed separately. The overall structure is parsed based on layout without parsing individual fields. In particular .cabal files are not tokenised. The second issue is easier. The original specification required that blank lines within a field include a leading `.` character. This applies to multi-paragraph descriptions. This syntax is totally unnecessary. The parser could cope fine without it. We should accept the convention for backwards compatibility but also allow ordinary blank lines. Multiple blank lines within a field should still be collapsed to one, and trailing blank lines within a field should be trimmed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/478> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #171: Add command to automagically create an initial cabal package
by Hackage 19 Dec '09

19 Dec '09

#171: Add command to automagically create an initial cabal package --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | --------------------------+------------------------------------------------- Don Stewart has a nice tool called mkcabal (http://www.cse.unsw.edu.au/~dons/code/mkcabal/) which creates an initial cabal package. It would be nice to have this built into the 'cabal' program itself so that "cabal create" or "cabal init" or similar would interactively create a cabal package. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/171> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #516: Maintain central haddock module index.
by Hackage 19 Dec '09

19 Dec '09

#516: Maintain central haddock module index. ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- The ghc api documentation includes a central index of [http://haskell.org/ghc/docs/latest/html/libraries/ all the modules in the core libraries]. Some people would like the same for all the modules provided by all the packages they have installed. See #206 for some of the previous discussion on this topic. The questions to resolve are where the index should be kept by default and how it should be configured (eg switched off). For example for a per-user install an index could live in `$HOME/.cabal/share/doc/index.html` but the equivalent is not appropriate for other prefixes like `/usr/local`. For global packages shipped by a distro the problem is much worse. We do not really want to have to have distro packages re-generating an html index every time they add and remove a package. Perhaps we should be looking at alternative solutions like using [http://live.gnome.org/devhelp devhelp] which can give easy access to installed documentation without maintaining a central index/catalog. Similar issues apply to a hoogle index. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/516> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2