December 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] #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

[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

[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] #598: Bogus build failures on HackageDB
by Hackage 16 Jan '10

16 Jan '10

#598: Bogus build failures on HackageDB --------------------------------+------------------------------------------- Reporter: mboes | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- HackageDB reports build failures for packages due to inconsistent dependencies. For instance, the dedukti package currently has a build failure because it depends on both bytestring and text. The latest version of bytestring is 0.9.1.5, but text is built using bytestring-0.9.1.4. This causes a build failure because the functions in text expect as arguments something of type ByteString from bytestring-0.9.1.4, not something of type ByteString from package bytestring-0,9.1.5. If the text package were built using the latest available version of bytestring, as would happen after a "cabal install text" on a fresh system, the problem would go away. Always building packages with the latest versions of their dependencies available isn't a solution, because dedukti could, for instance, depend on some specific version of bytestring yet text might happen to be built with another version on the Hackage server. Could there be a way to at least detect when build failures are due to inconsistent versions in dependencies, which is a problem specific to the Hackage server installation and not the package itself? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/598> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[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

patch applied (cabal): Get the correct value of $topdir on Windows with GHC 6.12.1
by Ian Lynagh 30 Dec '09

30 Dec '09

Wed Dec 30 12:46:13 PST 2009 Ian Lynagh <igloo(a)earth.li> * Get the correct value of $topdir on Windows with GHC 6.12.1 M ./Distribution/Simple/GHC.hs -4 +15 M ./Distribution/Simple/Haddock.hs -8 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20091230204613-3fd76-7e6e71f0…

1 0

patch applied (cabal): Revert the change to filter out deps of non-buildable components
by Duncan Coutts 29 Dec '09

29 Dec '09

Tue Dec 29 14:25:33 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Revert the change to filter out deps of non-buildable components Ignore-this: 7f6f18997e28b843422d2c55a8bce302 It does not work as intended and gives inconsistent results between cabal install and cabal configure. The problem with the approach was that we were filtering out the dependencies of non-buildable components at the end. But that does not help much since if one of the deps of the non-buildable component were not available then we would have failed earlier with a constraint failure. A proper solution would have to tackle it from the beginning, not just as a filter at the end. The meaning of build-depends and buildable: False needs more thought. M ./Distribution/PackageDescription/Configuration.hs -25 +6 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20091229222533-adfee-d801b824…

1 0