October 2008 - cabal-devel

[Hackage] #325: SHGetFolderPath requiered to configure cabal 1.4
by Hackage 01 Jul '09

01 Jul '09

#325: SHGetFolderPath requiered to configure cabal 1.4 ----------------------------+----------------------------------------------- Reporter: guest | 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: | ----------------------------+----------------------------------------------- i try to install cabal with ghc 6.8.3 on XP. i get the error message GHCi could not find the following symbols SHGetFolderPath i saw some old bugs mentioning this problem - what is a current fix? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/325> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #273: Provide a stable address for current Haddock documentation
by Hackage 12 Jun '09

12 Jun '09

#273: Provide a stable address for current Haddock documentation ----------------------------+----------------------------------------------- Reporter: guest | 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: | ----------------------------+----------------------------------------------- Documentation for version 0.1.1 of the Derive package is at http://hackage.haskell.org/packages/archive/derive/0.1.1/doc/html/ - but as soon as I upload a new version any documentation links will become out of date. It would be very useful if there was a stable URL where the documentation of the latest version of a package could be found. -- Neil Mitchell -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/273> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #318: Library cannnot be used when registered in-place on OS X
by Hackage 08 Jun '09

08 Jun '09

#318: Library cannnot be used when registered in-place on OS X ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Mac OS | ---------------------------------+------------------------------------------ I built and registered a library --inplace using cabal-install on Mac OS X 10.5.4 using cabal-install 0.5.1 and Cabal 1.4.0.1. I was unable to then use the package afterwards. It failed at link-time with: {{{ Linking Main ... ld: in /... blah .../lib/dist/build/lib-0.1.a, archive has no table of contents collect2: ld returned 1 exit status }}} After talking to Beelsebob and dcoutts on #haskell, I used '''ranlib''' on lib-0.1.a, and it worked. According to dcoutts: "it's because we run ranlib when we install it, but not when we first generate it." -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/318> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 14

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

03 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 01 Jun '09

01 Jun '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 18 Mar '09

18 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