May 2009 - cabal-devel

[Hackage] #532: Can't find libraries on Windows (Cabal 1.6.0.2)
by Hackage 27 Mar '10

27 Mar '10

#532: Can't find libraries on Windows (Cabal 1.6.0.2) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Windows | ----------------------------+----------------------------------------------- When trying to install the com-1.2.2 package from the Hackage tarball, configure reports that it cannot find the header file "include/WideStringSrc.h", which is part of the com-1.2.2 source, and is clearly there; and that it cannot find the libraries "kernel32", "user32", etc which are standard system libraries (the corresponding .lib files are part of the Platform SDK), even after giving it the library paths in every possible way (environment variable, command line option, modifying the "com.cabal" file). The former problem was mysteriously eliminated by some random modification of the .cabal file (namely, rearranging the order of the includes). The OS is Windows XP (servicepack 2). Everything works fine with Cabal 1.6.0.1. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/532> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #465: default global install on windows is a problem
by Hackage 21 Mar '10

21 Mar '10

#465: default global install on windows is a problem ----------------------------+----------------------------------------------- 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: normal | Ghcversion: 6.8.3 Platform: Windows | ----------------------------+----------------------------------------------- Lots of windows users have problems installing things globally. Some are using multi-user systems. More are using Vista where it seems that even when they are running as administrator they cannot install files in `C:\Program Files\`. We should revisit the decision to install globally and see if we cannot find a default that works better. Failing by default is bad. We may also want to try to improve the checking beforehand to check if we would have permissions to write into the target directories. If not we can fail at configure time rather than waiting until install time and failing ungracefully. This needs someone who knows and cares about windows. Particularly for the Vista aspects. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/465> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #251: link to the latest version of a package tar file
by Hackage 20 Mar '10

20 Mar '10

#251: link to the latest version of a package tar file ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | 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: | ----------------------------------+----------------------------------------- Dan Corson suggests: it would be good to have links to latest versions of a package file available for download. for example: something like {{{ http://hackage.haskell.org/packages/archive/arrows/latest.tar.gz }}} would be a link to {{{ http://hackage.haskell.org/packages/archive/arrows/0.4/arrows-0.4.tar.gz }}} this would greatly simplify automating installs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/251> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 5

[Hackage] #520: Use nice Unicode characters for inequalities
by Hackage 20 Mar '10

20 Mar '10

#520: Use nice Unicode characters for inequalities ----------------------------------+----------------------------------------- Reporter: Porges | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- This is a terribly minor request, but it would make the display nicer :) In dependency restrictions, instead of displaying (>=), (<=), use (≥), (≤). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/520> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #526: hugs-options aren't passed to ffihugs
by Hackage 19 Mar '10

19 Mar '10

#526: hugs-options aren't passed to ffihugs ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Options in hugs-options aren't passed through to ffihugs, most importantly -98 and +o are the ones we'd like to pass. For enabling the +o flag Hugs-Sept06 does not honor: * pragma {-# LANGUAGE !OverlappingInstances #-} * pragma {-# OPTIONS_HUGS +o #-} * cabal extensions: !OverlappingInstances And the -98 flag has similar issues. Therefore this is a real problem. Immediate solution: The options set in hugs-options should be passed to ffihugs as well. As of Cabal 1.6 they are not passed (verified by Duncan Coutts). The two programs accept all the same options, so this is valid. Ideal solution: Based on the extensions field, Cabal should automatically determine whether -98 and +o need to be enabled (for both hugs and ffihugs). A simple example demonstrating this bug can be found in Darcs repo http://community.haskell.org/~wren/cabal-ffihugstest -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/526> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #527: CPP not called before ffihugs
by Hackage 19 Mar '10

19 Mar '10

#527: CPP not called before ffihugs ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When building for Hugs, if CPP is being used in conjunction with FFI, then cpp/cpphs is not called before ffihugs is called. Thus, users must pass an -F flag to ffihugs in order to declare a code filter (and must pass all cpp-options to -F manually). For example: {{{ --ffihugs-option=-F'cpp -P -traditional -D__HUGS__ -D__BLAH__' }}} This requires duplicating the build specifications, which defeats the point of Cabal. Also it leads to tricky issues about ensuring the proper level of quoting/escaping. (e.g. using the plural, --ffihugs-options=..., breaks it. Wrapping the -F'cpp...' in double quotes breaks it.) A simple example of this bug can be seen in Darcs repo http://community.haskell.org/~wren/cabal-ffihugstest -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/527> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #284: Cannot upload packages that require specific cabal versions
by Hackage 19 Mar '10

19 Mar '10

#284: Cannot upload packages that require specific cabal versions --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- I have a package that requires a custom Setup.lhs.The package works for ghc 6.8.x and 6.6.x and, thus, the Setup.lhs script was designed to work with Cabal 1.2.x, the one that comes with ghc 6.8.x. This is clearly indicated in the cabal-version field. However, if I try to upload this package to hackage I get this error: {{{ hint-0.2.0.1/hint.cabal: This package requires Cabal version: >=1.2&&<1.3 }}} As a workaround I used cabal-version: >= 1.2 but now, although the description explicitly says that it works with ghc 6.8.x, hackage indicates that it fails to build. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/284> 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] #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