January 2010 - cabal-devel

[Hackage] #576: Show reverse dependencies
by Hackage 16 Mar '10

16 Mar '10

#576: Show reverse dependencies --------------------------------+------------------------------------------- Reporter: Lenny222 | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: dependencies Difficulty: easy (<4 hours) | Ghcversion: Platform: | --------------------------------+------------------------------------------- Suggestion: for every package show which other packages (if any) depend on it. Why? Many packages on http://hackage.haskell.org/ do not provide exmaples or documentation. It could be very helpful to look at packages which use the package on is interested in. This can be made easier if every package on http://hackage.haskell.org/ displays which other packages depend on it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/576> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #215: Overhaul support for package's tests
by Hackage 15 Mar '10

15 Mar '10

#215: Overhaul support for package's tests ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- The current support for running package's testsuites is almost uniformly unused and packages instead implement ad-hoc solutions which makes it hard for users to run the testsuites and impossible to automate on hackage. The current support is so trivial anyone who takes this task on can ignore it and start with a clean slate. A [http://www.haskell.org/pipermail/cabal-devel/2008-January/001661.html thread on the issue]. Here are some ideas for possible requirements: * Support tests even in the `Simple` build system. Do not require using the `build-type: Custom` just to be able to use tests. * Define a standard interface for returning test results from a testsuite to Cabal so they can be included into a build report and could be published on the hackage website or some other custom in-house test server. * Support for above interface in `QuickCheck` and `HUnit`. * Support for HPC when running testsuite programs, and gathering coverage results, again for reporting purposes. * We want to be able to run tests on a library that is not installed yet. This will rely on support in Cabal for registering a package inplace in a local package db, and building test code against that. * What about performance tests? What format should that use for reporting? The emphasis is on automation. A lot of interesting information becomes available with enough automation. For example we could compare on hackage which packages have more comprehensive testsuites (measured by HPC coverage). Or we could track performance over time. Once the data is available there is a lot we could do with it. It's not just for a public hackage server, developers could use this privately too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/215> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #517: make cabal install command support haddock options
by Hackage 02 Mar '10

02 Mar '10

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently the `cabal install` command supports just `--enable- documentation` which turns on library docs. The `cabal haddock` option has various other things like enabling docs for executables, specifying css files, linking to source code etc. Some or perhaps all of these would be useful when installing packages. This is not fundamentally difficult. The task is just to work out which options are useful (or perhaps all) and how to present the user interface (command line options and config file). Bonus points for a UI that is usable and orthogonal. See #206 for some of the previous discussion on this topic. See also #516 about maintaining a central haddock module index. For reference the current haddock command options are: {{{ Flags for haddock: -h --help Show this help text -v --verbose[=n] Control verbosity (n is 0--3, default verbosity level is 1) --builddir=DIR The directory where Cabal puts generated build files (default dist) --hoogle Generate a hoogle database --html-location=URL Location of HTML documentation for pre- requisite packages --executables Run haddock for Executables targets --internal Run haddock for internal modules and include all symbols --css=PATH Use PATH as the haddock stylesheet --hyperlink-source Hyperlink the documentation to the source code (using HsColour) --hscolour-css=PATH Use PATH as the HsColour stylesheet --with-haddock=PATH give the path to haddock --haddock-options=OPTS give extra options to haddock --haddock-option=OPT give an extra option to haddock (no need to quote options containing spaces) }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #627: Nonsense tarball permissions with sdist in Cabal 1.8.0.2
by Hackage 31 Jan '10

31 Jan '10

#627: Nonsense tarball permissions with sdist in Cabal 1.8.0.2 ----------------------------+----------------------------------------------- Reporter: draconx | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ----------------------------+----------------------------------------------- After upgrading to Cabal 1.8, running './Setup.lhs sdist' in any package is generating tarballs with bizarre permissions: - Every directory has mode 0755. - Every file has mode 0600. In particular, the executable bits from files are lost, and files should be group/world readable. Cabal 1.6 generates correct permissions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/627> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #611: protect users from themselves when they use sudo inappropriately
by Hackage 31 Jan '10

31 Jan '10

#611: protect users from themselves when they use sudo inappropriately ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Users sometimes get themselves into trouble with sudo. For example: {{{ sudo cabal install blah }}} or {{{ sudo cabal update }}} In both cases, the user is doing actions as root that modify their normal- user files. In the first case it will install a package into ~/.cabal/ but of course all the files owned by root, so the user cannot delete them again later. In the second case cabal will as root update the per-user package index. This will make further updates not as root fail, and worse because of a file permissions bug, the index will not be readable as their normal user. The aim would be to protect users from themselves and tell them when they're doing something that's almost certainly wrong. We could suggest alternatives, like don't use sudo if you wanted to do a per-user install, or use sudo and --global if you did. The tricky bit is making a suitably accurate test and making it possible to do the silly thing, if that's what the user really really wanted. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/611> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 31 Jan '10

31 Jan '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by duncan): Replying to [comment:21 AnttiJuhaniKaijanaho]: > For me as a user, this feature request is obvious and it's rather disappointing that Cabal will not support it. A simple makefile-based system, or even running ghc --make by hand!, does better on this count. With the makefile you are explicitly sharing modules and you specify the compile options once for each source file. For ghc --make you simply get wrong results (it does not track when you change compile options). As a design choice (one made long ago) Cabal lets you specify different compile options for the same source file when used in different components. > What about allowing specifying a list of modules common to all executables? That would help me. (Or, of course, if the "private libraries" are lightweight enough that I just have to list the modules that are included in it, that's good enough.) That would be similar though I think I prefer the private library approach, it's a bit more flexible. The "common modules" approach does not work for sharing modules between a library and an executable with ghc because the module need to be compiled differently. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:22> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 28 Jan '10

28 Jan '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by AnttiJuhaniKaijanaho): For me as a user, this feature request is obvious and it's rather disappointing that Cabal will not support it. A simple makefile-based system, or even running ghc --make by hand!, does better on this count. What about allowing specifying a list of modules common to all executables? That would help me. (Or, of course, if the "private libraries" are lightweight enough that I just have to list the modules that are included in it, that's good enough.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:21> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 28 Jan '10

28 Jan '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by duncan): Replying to [comment:19 AnttiJuhaniKaijanaho]: > From what I understand, the patch above does not solve the original request: the useless rebuilding of Other-Modules shared by multiple Executables. Right the current system does not help for packages with several executables but no library. For that we need to support convenience / private libraries as in #276. I do not plan to implement ad-hoc / implicit / opportunitsic sharing of .o files. It is too hard to implement at the moment. It requires tracking lots of information to check if the sharing is safe. It might become possible in a future build system that obsessively tracks all dependencies. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:20> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 27 Jan '10

27 Jan '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Changes (by AnttiJuhaniKaijanaho): * cc: antti-juhani@… (added) Comment: From what I understand, the patch above does not solve the original request: the useless rebuilding of Other-Modules shared by multiple Executables. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:19> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #600: Cabal should use -dynamic linking for executable when package configured --enable-shared
by Hackage 26 Jan '10

26 Jan '10

#600: Cabal should use -dynamic linking for executable when package configured --enable-shared ----------------------------+----------------------------------------------- Reporter: juhp | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ----------------------------+----------------------------------------------- With ghc-6.12 {{{--enable-shared}}} now works well to create shared libraries, however executable binary programs generated with Cabal are always statically linked. When configuring with --enable-shared they should be dynamically linked if possible. Here is a patch tested successfully with ghc-6.12 RC1 on Linux. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/600> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9