September 2009 - cabal-devel

[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] #234: track installed files to allow uninstall
by Hackage 24 Jan '10

24 Jan '10

#234: track installed files to allow uninstall -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- `cabal-install` needs to be able to track all the files it installs so that it'll be possible to uninstall packages. The copy/install code should be extended to be able to generate a list of files and hashes of files that will be installed. `cabal-install` could use that to write out a manifest file and use that later to allow uninstalling. One solution might be to restructure the install code to gather the source files that it would install rather than just doing it. Once that list of files is known we can copy them all in one go, and do other things like check for clashing target files and generate manifests etc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/234> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds.
by Hackage 16 Jan '10

16 Jan '10

#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | --------------------------------+------------------------------------------- Given these packages: C depends on B, B depends on A. A failed to build, B and C were uploaded later and failed also. Later, A was fixed, bumped version, re-uploaded. B did not need fixing, so remained untouched. C was also fixed, bumped version, re-uploaded. Finally, A rebuilt OK, B was not scheduled for rebuilding, C failed because B was still failed. It is requested that once a package that failed to build is updated and builds, all packages immediately dependent upon it are scheduled for rebuild. Then the same logic applies to those that rebuilt OK (their dependencies are scheduled for rebuild). Thanks. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/462> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ?
by Hackage 14 Jan '10

14 Jan '10

#207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ? --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: misc | Version: HEAD Severity: normal | Keywords: tags source tagfile Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------+------------------------------------------------- == Introduction == I personally depend on tags because the source code only tells what is really going on. So it would be incredible useful to not only get information using ghci after loading libs but also beeing able to jump to all functions you might be using anywhere (The only solution providing this in all cases is uning tags, right? Because cpp defines can introduce new functions.. To be able to jump to the code source must be installed along with libs (the way you can optionally install haddock docs) == Use case: == setup configure --with-tags --install-source (or something like that) setup build && setup install do this for each dependency given in the .cabal file (VIM:) let tags+=system('ghc-pkg --query-tagfile-location haskell98-1.0.0.0') == Issues: == * Which tool to generate tag files? * ghc(i) when targeting ghc * the hasktags program shipping with ghc * some others? * Tagfile path type relative or absolute? * absolute: After moving/ installing the sources the tagfile must be patched * relative: Do editors take the right base directory to find source files? * When to invoke the tagfile generating program? * Perfect case would be after all preprocessing has been done (Thus the tagging program should understand line number changing comments!) * Template Haskell? ( This is really tricky I think ) * Hmm sorted tagfiles would be useful as well :) == alternatives ? == If you do not think this is useful (mandatory?) how do you lookup code? (Yes I know hoogle :) perhaps using Eclipse or Visual Studio? I'd like to start implementing this somehow the next weeks. So don't hesitate and start discussing Marc Weber -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/207> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 5

[Hackage] #466: libdir does not follow prefix on windows
by Hackage 29 Dec '09

29 Dec '09

#466: libdir does not follow prefix on windows ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: Windows | ------------------------------+--------------------------------------------- On Windows, for some reason, the `--libdir` is set independently of the `--prefix`. This is actually quite annoying because it's not discoverable and when you do discover it you've got to set the libdir along with the prefix on the command line or in the config file. Apparently there was some reason why it is done this way. We should find out what that reason is and determine if it is valid and if so if there is any way to make it work in a less annoying way. If we think it will not break anything then changing the default is trivial. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/466> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #244: Add Changelog summary feature to sdist
by Hackage 22 Dec '09

22 Dec '09

#244: Add Changelog summary feature to sdist ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- In a discussion with Audrey Tang, she mentioned that a very nice feature of CPAN which she missed in Hackage was standardized changes files. It seems to me that one way to acheive this would be to add a --changelog flag to sdist (or maybe make default). This call 'darcs changes' and copy into the ChangeLog everything up to 2 tags ago. (2 tags because the first tag might be you preparing for a release). I'd imagine parsing would be dead easy: 'lines' to split it up into individual entries, and then take until you hit a 'tagged' entry. If the resulting list is length of 1, then take again. So you'd go 'runhaskell Setup sdist --changelog', and ChangeLog in the tarball would have, say, for Monadius: ---- Wed Feb 20 18:37:42 EST 2008 gwern0(a)gmail.com tagged 0.91 Wed Feb 20 18:37:29 EST 2008 gwern0(a)gmail.com * misc improvements: newtype, cabal, fmt Fri Dec 7 16:23:53 EST 2007 gwern0(a)gmail.com * rm extra source-files The line was originally there because there is an icon for Monadius in the source-files and some sort of Windows resource text file telling Windows to use it; I'm removing the mention of them in the .cabal because I don't think Cabal handles that right now. Thu Dec 6 16:30:31 EST 2007 gwern0(a)gmail.com * whitespace changes, add haskell98 to dependencies Tue Dec 4 13:46:38 EST 2007 gwern0(a)gmail.com * mv cabal field so hackage doesn't complain Tue Dec 4 13:10:47 EST 2007 gwern0(a)gmail.com * cabal fixes Tue Dec 4 08:32:25 EST 2007 gwern0(a)gmail.com tagged 0.91 ---- At this point, Hackage could be updated to link to it in the same way as it does for the .cabal file. That way, people could then easily take a look and see what's new since the last version. (Said facility is currently a little difficult unless the package authors manually maintain a ChangeLog and specifically include it into the tarball; you'd still have to either go to the repo or download the tarball simply to find out what's different from the older packages.) --gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/244> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 14

[Hackage] #331: pkg-config error messages could be better
by Hackage 22 Dec '09

22 Dec '09

#331: pkg-config error messages could be better ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Currently if you `cabal install X11-xft` but don't have the xft development package installed you get this during configure: {{{ cabal: The pkg-config package xft is required but it could not be found. }}} What is not immediately clear is that this is a native package and thus not something that `cabal-install` could have gone and fetched. So the wording of this message could be improved. Perhaps mentioning both in general terms and then specifically. For example saying that the development files for xft are not installed and that the user probably can and should install a native package that provides it. Specifically it's looking for a xft.pc file that pkg-config uses to tell is what compiler flags to use to use xft. A related problem is that the message is somewhat lost in the noise because we print the error to stdout rather than throwing it as an exception that we could print in the final summary. This problem is particulary bad when we have to have error message cross process boundaries, ie when cabal-install invokes a setup program. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/331> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #515: --extra-lib-dirs= should add -R/-rpath to hsc2hs calls
by Hackage 22 Dec '09

22 Dec '09

#515: --extra-lib-dirs= should add -R/-rpath to hsc2hs calls ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Currently the `--extra-lib-dirs=` flag is only used to add extra `-L` flags in calls to `gcc`, `hsc2hs` etc. On systems where `--extra-lib- dirs=` is necessary it's almost always the case that we also need `-R`/`-rpath` too. Apparently `-rpath` is somewhat controversial and some people argue against using it. However one case where it is clearly necessary is in invoking `hsc2hs`. This is because `hsc2hs` compiles, links and runs a C program. The program is run once on the host machine and never installed or distributed. So all the usual arguments against `-rpath` do not apply. Hard coding the paths of libs is fine since the program is only used once, in the build tree. It's also essential for it to actually work. Here's an example log from someone hitting this problem: {{{ $ cabal install pcre-light --extra-include-dirs=/usr/local/include --extra-lib-dirs=/usr/local/lib Resolving dependencies... 'pcre-light-0.3.1' is cached. Configuring pcre-light-0.3.1... Preprocessing library pcre-light-0.3.1... dist/build/Text/Regex/PCRE/Light/Base_hsc_make: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory running dist/build/Text/Regex/PCRE/Light/Base_hsc_make failed command was: dist/build/Text/Regex/PCRE/Light/Base_hsc_make >dist/build/Text/Regex/PCRE/Light/Base.hs }}} On this system it appears that `/usr/local/lib` is not on the default static linker path, or the default dynamic linker path. So we need `-L/usr/local/lib` for the static linker and `-R/usr/local/lib` for the dynamic linker. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/515> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #543: cabal requires root privileges in order to modify files in /usr/lib/ghc-6.8.2
by Hackage 22 Dec '09

22 Dec '09

#543: cabal requires root privileges in order to modify files in /usr/lib/ghc-6.8.2 ----------------------------+----------------------------------------------- Reporter: nr | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: ghc package.conf Difficulty: unknown | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- cabal requires root privileges in order to modify files in /usr/lib/ghc-6.8.2. I'm reporting this as a defect in the tool, since it was told to install in /usr/local/cabal, and it seems unreasonable that cabal should require root privileges when these are not required for installing into its target directory. I am less well informed about the Linux Filesystem Standard, but I believe that files in /usr/lib are supposed to be immutable. If I'm correct, cabal is violating that standard in a major way. If you must have a mutable {{{package.conf}}}, put it in {{{/var/lib/ghc-6.8.2}}}, and make it group writable by a suitable group (which you may need to create). I'm cc-ing ghc-devel on this one because the two groups will probably have to cooperate. {{{ : nr@homedog 5548 ; cabal install graphmod Resolving dependencies... Downloading dotgen-0.2... Configuring dotgen-0.2... Preprocessing library dotgen-0.2... Building dotgen-0.2... [1 of 1] Compiling Text.Dot ( Text/Dot.hs, dist/build/Text/Dot.o ) /usr/bin/ar: creating dist/build/libHSdotgen-0.2.a Installing library in /usr/local/cabal/lib/dotgen-0.2/ghc-6.8.2 Registering dotgen-0.2... Reading package info from "dist/installed-pkg-config" ... done. Unable to rename "/usr/lib/ghc-6.8.2/package.conf" to "/usr/lib/ghc-6.8.2/package.conf.old" Saving old package config file... ghc-pkg.bin: /usr/lib/ghc-6.8.2/package.conf: renameFile: permission denied (Permission denied) Downloading haskell-lexer-1.0... Configuring haskell-lexer-1.0... Preprocessing library haskell-lexer-1.0... Building haskell-lexer-1.0... [1 of 6] Compiling Language.Haskell.Lexer.Position ( Language/Haskell/Lexer/Position.hs, dist/build/Language/Haskell/Lexer/Position.o ) Language/Haskell/Lexer/Position.hs:25:4: Warning: Pattern match(es) are overlapped In a case alternative: '\n' -> ... [2 of 6] Compiling Language.Haskell.Lexer.Tokens ( Language/Haskell/Lexer/Tokens.hs, dist/build/Language/Haskell/Lexer/Tokens.o ) [3 of 6] Compiling Language.Haskell.Lexer.Utils ( Language/Haskell/Lexer/Utils.hs, dist/build/Language/Haskell/Lexer/Utils.o ) [4 of 6] Compiling Language.Haskell.Lexer.Lex ( Language/Haskell/Lexer/Lex.hs, dist/build/Language/Haskell/Lexer/Lex.o ) [5 of 6] Compiling Language.Haskell.Lexer.Layout ( Language/Haskell/Lexer/Layout.hs, dist/build/Language/Haskell/Lexer/Layout.o ) [6 of 6] Compiling Language.Haskell.Lexer ( Language/Haskell/Lexer.hs, dist/build/Language/Haskell/Lexer.o ) /usr/bin/ar: creating dist/build/libHShaskell-lexer-1.0.a Installing library in /usr/local/cabal/lib/haskell-lexer-1.0/ghc-6.8.2 Registering haskell-lexer-1.0... Reading package info from "dist/installed-pkg-config" ... done. Unable to rename "/usr/lib/ghc-6.8.2/package.conf" to "/usr/lib/ghc-6.8.2/package.conf.old" Saving old package config file... ghc-pkg.bin: /usr/lib/ghc-6.8.2/package.conf: renameFile: permission denied (Permission denied) cabal: Error: some packages failed to install: dotgen-0.2 failed during the final install step. The exception was: exit: ExitFailure 1 graphmod-1.1.3 depends on haskell-lexer-1.0 which failed to install. haskell-lexer-1.0 failed during the final install step. The exception was: exit: ExitFailure 1 : nr@homedog 5549 ; }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/543> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2