December 2008 - cabal-devel

[Hackage] #185: Temporary executables leave foo.exe.manifest files behind
by Hackage 02 Jun '09

02 Jun '09

#185: Temporary executables leave foo.exe.manifest files behind ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Windows | ----------------------+----------------------------------------------------- When Cabal creates and runs a temporary program, as it appears to do with hsc when running over the base libraries doing haddock, it leaves a manifest behind in dist. On Windows, ghc --make with 6.8.1 produces a foo.exe and a foo.exe.manifest. Cabal deletes the former, but not the latter. Very minor, but should be easy to fix too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/185> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #369: Version range printing is inconsistent
by Hackage 31 May '09

31 May '09

#369: Version range printing is inconsistent ----------------------------+----------------------------------------------- Reporter: nominolo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.9 Platform: | ----------------------------+----------------------------------------------- When configuring a package with the following build-depends: {{{ build-depends: base >= 4 && < 5, ghc-paths >= 0.1 && < 0.2, ghc >= 6.10 && < 6.12, ghc-syb >= 0.1 && < 0.2, directory >= 1.0 && < 1.1 }}} configuring fails with: {{{ Setup: At least the following dependencies are missing: ghc-paths ==0.1.* && ==0.1.*, ghc-syb ==0.1.* }}} Note the superfluous {{{ && ==0.1.*}}} in the first missing dependency. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/369> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #231: "buildable: False" should fail the current configuration
by Hackage 27 Apr '09

27 Apr '09

#231: "buildable: False" should fail the current configuration ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Currently resolving configurations does not take account of the `buildable` field. It should act rather like `build-depends: non- existant`, though with a different error message. If possible the error message should relate to the guard condition expression (the conjunction if there are several nested guards). At the moment it is not considered at all and we don't notice that the package cannot be built until the build step, rather than the configure step. One problem is that it's not clear if `buildable: False` is always fatal. People sometimes do that for test executables that are not supposed to be installed. So what should the behaviour be? The lib or only exe failing to configure must be an error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/231> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #338: use of HTTP needs overhauling
by Hackage 24 Apr '09

24 Apr '09

#338: use of HTTP needs overhauling ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ We're not using HTTP the protocol or HTTP the package effectively * As I understand it, the HTTP lib buffers the entire http download in memory rather than returning it lazily, so we cannot stream it to disk. It's also all done using `String`. * We do not check (and nor does the HTTP lib) for truncated downloads. That is where the `Content-Length` header differs from the actual length. * We do not cache the ETag so we cannot optimise the case of re- downloading an unchanged index. * We make a new tcp connection for each download, rather than doing all downloads within a single browse session. * We are not doing downloads concurrent with package builds. We should probably use a dedicated thread for downloads. It should serialise downloads and use a single browse session. Even without support for streaming the body directly we could at least write files atomically, checking length header. And also cache the ETag. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/338> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #289: symlink binaries into ~/bin
by Hackage 23 Apr '09

23 Apr '09

#289: symlink binaries into ~/bin ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Currently cabal-install uses `--prefix=$HOME/.cabal` and does not specify `--bindir` so we use `$HOME/.cabal/bin` as the bindir. Obviously this is not on the `$PATH` by default. It would be trivial to specify `--bindir=$HOME/bin` however the worry is that we would be stomping on programs that the user has already installed there. One solution is to continue to install into `$HOME/.cabal/bin` and then to make symlinks into `$HOME/bin` if the target name does not already exist. If the name does exist we could give a warning and let the user sort it out. Of course we need to be able to overwrite our own symlinks. We know it's a symlink we're allowed to overwrite if it links into `$HOME/.cabal/bin`. It would be nice to install into `$HOME/.cabal/bin` using versioned binary names (Cabal supports that now) and symlink the generic name into `$HOME/bin`. We can discover the names of the binary we're installing by checking the executable names in the `PackageDescription`. Of course this has to be an optional feature since not everyone wants it and there are no symlinks on windows. I'd imagine we'd have it in the `~/.cabal/config` file something like: {{{ prefix: $HOME/.cabal -- bindir: $HOME/.cabal/bin symlink-bindir: $HOME/bin }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/289> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 17

[Hackage] #266: cabal haddock plus cpp preprocessing with relative #include files
by Hackage 17 Mar '09

17 Mar '09

#266: cabal haddock plus cpp preprocessing with relative #include files ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic Bug 2: cabal haddock fails $ cabal haddock Preprocessing library homeomorphic-0.1... Running Haddock for homeomorphic-0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: base-3.0.1.0, QuickCheck-1.1.0.0, mtl-1.1.0.0, containers-0.1.0.1 dist/build/tmp/Data/Homeomorphic/Hash1.hs:4:0: Include/Hash.hs: No such file or directory This one may well be my fault, if some extra magic is required for the haddock with CPP, but not the building - but that seems weird, if there is enough info to build the file, surely there is enough info to haddock it Duncan says: Right, there is no such guarantee at the moment. That's because ghc --make can find things by import chasing where Cabal needs more stuff specified explicitly. One day when Cabal does the import chasing they'll be consistent. In this case though it doesn't look like on of those problems. It seems to be because for haddock we're copying files to dist/ and then running cpp on them. That means of course that relative #includes do not work. It's not entirely clear to me why we are copying them before running cpp and not just running cpp on the files from their original locations. Please file a ticket for this one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/266> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #188: file extensions
by Hackage 16 Mar '09

16 Mar '09

#188: file extensions --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Linux | --------------------------+------------------------------------------------- GHC ignores Objective C sources unless -x c is passed to it on the command line before the source files. As far as I could tell there is no way to pass that option to GHC through Cabal so no .m files ever get built (well.. not completely true - setting ghc-options works but that breaks compilation of Haskell code). One way to get this to work would be to just add some extra code in Cabal to automatically pass -x c for .m files. This is probably a bad idea as someone might want or need to compile files using some other extension at some point. Another option is add some way of specifying compile options on a per-file (or group of files) basis: setting ghc-options to -x c just for one set of files. Still very limited but it's an improvement over the first option. Third option I can think of is to add a way of specifying compiler/extension pairs in Cabal so given compilers are automatically used to compile files with corresponding extensions. Depending on how much time I have I might look into adding this functionality myself but would like some feedback on which approach to take. Otherwise I might have to stick with autotools and ignore Cabal until it gets a bit more mature and flexible. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/188> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #381: broken link cabal user guide
by Hackage 11 Mar '09

11 Mar '09

#381: broken link cabal user guide ----------------------------------+----------------------------------------- Reporter: luntain | Owner: Type: defect | Status: new Priority: low | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.3 Platform: | ----------------------------------+----------------------------------------- http://www.haskell.org/cabal/release/latest/doc/users-guide/builders.html #setup-test contains a broken link with label: Distribution.Simple the fragment which contais the link reads: "See Distribution.Simple for information about creating hooks and using defaultMainWithHooks." -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/381> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #380: Ability to blacklist packages that are on hackage
by Hackage 11 Mar '09

11 Mar '09

#380: Ability to blacklist packages that are on hackage ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: wishlist blacklist Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Sometimes there are packages on hackage that I don't want to install, perhaps ever. Maybe there is a buggy release I'm trying to avoid, or something of that nature. So, my proposal is a user defined blacklist. I think the version specification could work just like that of a .cabal file. I also think cabal should tell you when it skips a dependency due to blacklisting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/380> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #309: cabal install should recognize if package was already configured
by Hackage 09 Mar '09

09 Mar '09

#309: cabal install should recognize if package was already configured ---------------------------------+------------------------------------------ Reporter: bfr | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ If I first configure an unpacked package inside its source directory cabal configure --prefix=/my/path --flags=whatever and then afterwards do cabal install then the configure options I gave before are not recognized by the 'cabal install'. Instead, 'cabal install' without a package name argument should inspect whether the package is already configured and use whatever options have been set. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/309> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1