May 2009 - cabal-devel

Paths module in package description or not?
by Henning Thielemann 01 Jun '09

01 Jun '09

Consider http://code.haskell.org/mohws/mohws.cabal When I include Paths_mohws as Other-Modules, 'cabal haddock' aborts with: thielema@euler:~/programming/haskell/mohws> cabal haddock Preprocessing library mohws-0.2.0.1... Preprocessing executables for mohws-0.2.0.1... Running Haddock for mohws-0.2.0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Preprocessing library mohws-0.2.0.1... Preprocessing executables for mohws-0.2.0.1... cabal: can't find source for module Paths_mohws When I remove Paths_mohws from Other-Modules then the library and executables in the package can be built successfully. But when I compile an executable outside the package, then I get a linker error: parallelweb> cabal install Resolving dependencies... Configuring parallelweb-0.0.2... Preprocessing executables for parallelweb-0.0.2... Building parallelweb-0.0.2... Linking dist/build/parallelweb/parallelweb ... /home/thielema/.cabal/lib/mohws-0.2.0.1/ghc-6.10.3/libHSmohws-0.2.0.1.a(Configuration.o): In function `sfyj_info': (.text+0x2d1f): undefined reference to `mohwszm0zi2zi0zi1_Pathszumohws_a7_closure' /home/thielema/.cabal/lib/mohws-0.2.0.1/ghc-6.10.3/libHSmohws-0.2.0.1.a(Configuration.o): In function `seCS_info': (.text+0x86bb): undefined reference to `__stginit_mohwszm0zi2zi0zi1_Pathszumohws_' collect2: ld returned 1 exit status cabal: Error: some packages failed to install: parallelweb-0.0.2 failed during the building phase. The exception was: exit: ExitFailure 1 I use: $ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library Which way is the intended one? Include Paths_mohws in package description or not? In general, shall automatically generated files appear in Cabal file? I think they should not, since they are not part of the distribution tarball. So can I consider the linker error being a bug?

2 1

[Hackage] #533: Cabal file in UTF-8 format can not be handled by Cabal
by Hackage 31 May '09

31 May '09

#533: Cabal file in UTF-8 format can not be handled by Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: UTF-8 Difficulty: unknown | Ghcversion: 6.10.1 Platform: Windows | ----------------------------+----------------------------------------------- According to http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html , a .cabal file should be a Unicode UTF-8 text file; when I change the file to UTF-8 with notepad, Cabal can not handle it: > runhaskell Setup configure Setup: xyz.cabal:1: unrecognised field or section: "\65279Name: xyz" Changing this file back to ANSI solves the problem. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/533> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal): Ignore a byte order mark (BOM) when reading UTF8 text files
by Duncan Coutts 31 May '09

31 May '09

Sun May 31 15:50:08 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Ignore a byte order mark (BOM) when reading UTF8 text files Yes of course UTF8 text files should not use the BOM but notepad.exe does anyway. Fixes ticket #533. M ./Distribution/Simple/Utils.hs -3 +12 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090531225008-adfee-c4e4ae80…

1 0

[Hackage] #558: Spec needs updating for hc-pkg
by Hackage 31 May '09

31 May '09

#558: Spec needs updating for hc-pkg ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Section 3.3 describes the hc-pkg tool: http://haskell.org/cabal/proposal/x272.html#AEN351 It leaves these questions unanswered: {{{ Note: Can we give the --user flag to hide, expose, describe? Can we register a package that is already registered? What if it's registered as a global package and we register it as a user package? }}} It makes this suggestion which has never been implemented: {{{ Note: Some of these commands (unregister, hide, and describe) make sense for package IDs which offer a range, such as "hc-pkg unregister hunit<2.3". }}} Also, we should standardise `hc-pkg dump` and the format it produces. It's the only sensible way for tools to get that info. Otherwise they must call `hc-pkg describe` 100's of times which is unreasonably slow. There is no method to construct a new package database. There is nothing specified to allow for specific package databases. Should we standardise ghc-pkg's `--force` or `--force-files`? It may also be useful to allow a package to be registered or checked against a virtual root, eg when the files are not yet installed. There is no specification on the meaning of stacks of package databases, ie how do we interpret package collections when we merge several. Current semantics is a bit odd when user packages shadow global packages. Partly this is standardising existing practice and partly it's asking for extensions. If we accept the relative paths extension that that must be documented too along with a way to find the global and user package dbs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/558> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #557: Spec does not define the installed package info fields
by Hackage 31 May '09

31 May '09

#557: Spec does not define the installed package info fields ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal specification | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------------+----------------------------------------- http://haskell.org/cabal/proposal/x272.html#IPD Section 3.4 of the spec "Syntax of installed package description" is empty. It should define all the fields and their contents. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/557> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 31 May '09

31 May '09

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn(a)bringert.net | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by duncan): Thanks to Stephen we've got this one done finally. You can now have executables specify `build-depends` on the library in the same package. You must specify `cabal-version: >= 1.8` to use this feature. Note that the executable must not specify the same `hs-src-dirs` as the library or it'll just pick up the source files rather than using the built library. Remaining: * Add a QA check to make sure people are not specifying internal deps without using `cabal-version: >= 1.8` * Update the user guide to explain the feature and restrictions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:13> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): executables can now depend on a library in the same package.
by Duncan Coutts 31 May '09

31 May '09

Sun May 31 15:07:20 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * executables can now depend on a library in the same package. Fixes ticket #89. The library gets registered into an inplace package db file which is used when building the executables. Based partly on an original patch by Stephen Blackheath. M ./Distribution/Simple/Build.hs -5 +29 M ./Distribution/Simple/Configure.hs -2 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090531220720-adfee-1a9ecf92…

1 0

[Hackage] #556: local config files
by Hackage 31 May '09

31 May '09

#556: local config files ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ It would be nice if I could locally (for a project/directory) store the options I want to pass to "cabal configure". An example use case would be in the darcs project which has a flag "-ftype-witnesses". We don't want to inflict this on most users because it increases our compile time, but for developers of certain branches of darcs want to be systematically using this flag so that they can catch errors. These developers could just "cabal configure -ftype-witnesses", but then if they do a "cabal clean" for any reason, the next time they run "cabal configure", they may forget to pass the flag along. To be clear, this is something to be used by individual developers; it's not something we want for the .cabal file itself. Duncan says that this would be a bit like a local .ghci file, if it helps. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/556> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[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

patch applied (cabal-install): Simplify version ranges before printing in error messages
by Duncan Coutts 31 May '09

31 May '09

Sun May 31 12:13:46 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Simplify version ranges before printing in error messages Part of ticket #369 M ./Distribution/Client/Dependency/TopDown.hs -8 +18 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090531191346-adfee-…

1 0