December 2008 - cabal-devel

[Hackage] #317: filter -threaded when profiling is on
by Hackage 22 Jan '09

22 Jan '09

#317: filter -threaded when profiling is on ----------------------------+----------------------------------------------- Reporter: gbacon | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- As a service to the community, please filter -threaded when profiling is on. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/317> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #179: support GHC's main-is extension
by Hackage 21 Jan '09

21 Jan '09

#179: support GHC's main-is extension --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | --------------------------+------------------------------------------------- Query on haskell-cafe: http://haskell.org/pipermail/haskell- cafe/2007-November/034686.html {{{ It seems the meaning of the -main-is switch for GHC and the Main-Is build option for Cabal executables differ. With GHC, I can point to any function "main" in any module, but in Cabal I must point to a filename with precisely the module name "Main". This is tying my hands with regard to organizing a default executable and exposing some of its functionality as a library. Is there a way to get around this restriction? Concretely, I want to point Cabal's Main-Is to Program/Main.hs which starts with module Program.Main where instead of just module Main where }}} So in GHC it has this meaning: http://haskell.org/ghc/docs/latest/html/users_guide/options-phases.html #options-linker {{{ -main-is thing The normal rule in Haskell is that your program must supply a main function in module Main. When testing, it is often convenient to change which function is the "main" one, and the -main-is flag allows you to do so. The thing can be one of: A lower-case identifier foo. GHC assumes that the main function is Main.foo. An module name A. GHC assumes that the main function is A.main. An qualified name A.foo. GHC assumes that the main function is A.foo. }}} In Cabal the {{{main-is:}}} field specifies the '''file name''' of the Main module. GHC's {{{-main-is}}} flag is an extension to Haskell that is not supported by the other Haskell implementations. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #306: can't figure out how to use data-files
by Hackage 20 Jan '09

20 Jan '09

#306: can't figure out how to use data-files ----------------------------+----------------------------------------------- Reporter: claus | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.9 Platform: | ----------------------------+----------------------------------------------- looking into the docs, `data-files` seem easy. but when i try this: {{{ -- p.cabal name: p version: 0 license: BSD3 build-depends: base build-type: Simple exposed-modules: P data-files: file }}} {{{ -- Setup.hs import Distribution.Simple main = defaultMain }}} {{{ -- P.hs module P(file) where import Paths_p file = getDataFileName "file" }}} {{{ -- file data here }}} installation succeeds, but usage doesn't: {{{ $ runhaskell Setup.hs --version Cabal library version 1.5.1 $ runhaskell Setup.hs configure --prefix=c:/ghc/libraries --datadir='$prefix' Configuring p-0... $ runhaskell Setup.hs build -v Creating dist\build (and its parents) Creating dist\build\autogen (and its parents) Preprocessing library p-0... Building p-0... Building library... Creating dist\build (and its parents) c:\ghc\ghc-6.9.20080514\bin\ghc.exe -package-name p-0 --make -hide-all- packages -i -idist\build -i. -idist\build\autogen -Idist\build -odir dist\build -hidir dist\build -stubdir dist\build -package ba se-3.0 -O P [1 of 2] Compiling Paths_p ( dist\build\autogen\Paths_p.hs, dist\build\Paths_p.o ) [2 of 2] Compiling P ( P.hs, dist\build\P.o ) Linking... c:\ghc\ghc-6.9.20080514\bin\ar.exe q dist\build\libHSp-0.a dist\build\P.o c:\ghc\ghc-6.9.20080514\bin\ar.exe: creating dist\build\libHSp-0.a c:\ghc\ghc-6.9.20080514\gcc-lib\ld.exe -x -r -o dist\build\HSp-0.o.tmp dist\build\P.o $ runhaskell Setup.hs install Installing: c:/ghc/libraries\p-0\ghc-6.9.20080514 Registering p-0... Reading package info from "dist\\installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. }}} {{{ $ ghcii.sh GHCi, version 6.9.20080514: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :browse P file :: IO FilePath Prelude> P.file Loading package p-0 ... linking ... <interactive>: c:/ghc/libraries\p-0\ghc-6.9.20080514\HSp-0.o: unknown symbol `___stginit_pzm0_Pathszup_' ghc.exe: unable to load package `p-0' Prelude> :set -package p package flags have changed, ressetting and loading new packages... Loading package p-0 ... linking ... ghc.exe: c:/ghc/libraries\p-0\ghc-6.9.20080514\HSp-0.o: unknown symbol `___stginit_pzm0_Pathszup_' ghc.exe: unable to load package `p-0' > }}} what am i doing wrong? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/306> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #310: Install with multiple compilers
by Hackage 20 Jan '09

20 Jan '09

#310: Install with multiple compilers ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- It would be nice to be able to install a package with multiple compilers in one pass. For example, with the current Setup.[l]hs interface, {{{runhaskell Setup.hs configure --ghc --hugs --jhc}}} should configure for all three compilers, and then the build and install steps should perform the steps for all three as well. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/310> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

darcs patch: Fallback onto simpleHTTP when Network.Browser fails
by Stephen Hicks 18 Jan '09

18 Jan '09

Sat Oct 11 11:45:25 EDT 2008 Stephen Hicks <sdh33(a)cornell.edu> * Fallback onto simpleHTTP when Network.Browser fails

2 4

[Hackage] #399: More information in the Paths_pkg.hs module, or a new module
by Hackage 17 Jan '09

17 Jan '09

#399: More information in the Paths_pkg.hs module, or a new module ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- There is more information about the system or about the package or configuration that we could include into a generated module. For example: * OS name (from standard enum names, not System.Info.os) * Arch name (similarly) * Compiler used for build * Package version (perhaps moved out of the `Paths_` module) * Other .cabal file package details (as Strings) * `x-foo` extension fields * license enum * authors, copyright * synopsis / description * home page, bug report url * configuration flag values * System details * big or little endian * Revision control context * git hash * darcs context -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/399> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #401: better support for multi-valued configuration flags
by Hackage 17 Jan '09

17 Jan '09

#401: better support for multi-valued configuration flags ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- For some packages one has to pick one of several mutually exclusive options. For example `yi` has a number of console or gui front ends. That can be expressed in terms of boolean flags but it's a little clumsy. We should consider adding some syntactic sugar. Currently it can be expressed by excluding the choice of picking none: {{{ if flag(gtk) ... if flag(vty) ... if flag(coca) && os(osx) ... if ! ( flag(gtk) || flag(vty) || (flag(coca) && os(osx)) ) buildable: false }}} That doesn't exclude the possibility of picking two options of course. In some cases we would want the options to be mutually exclusive and in others we would want to simply force the choice of one option, but multiple options might be possible. So the question is what kind of syntactic sugar would we like, how would it translate and how would it be exposed to package managers. eg: {{{ flag gui values: gtk, vty, coca if flag(gui==gtk) ... etc }}} and it'd translate into boolean choices that forced a choice of one flag being true and the others false. Needs some thought. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/401> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #400: fail and warnings for build configurations
by Hackage 17 Jan '09

17 Jan '09

#400: fail and warnings for build configurations ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- People expect `buildable: False` to fail the current configuration (rather than letting it configure and then not working at build time). But perhaps we should make that more explicit and allow a message, eg instead of: {{{ if os(windows) buildable: False }}} allow {{{ if os(windows) fail: it doesn't work on windows because, blah blah blah }}} And similarly we might want to warn users about selecting particular configurations eg: {{{ if flag(http) ... else warn: no http implementation selected, only local operations will be possible. You probably really want some http implementation. }}} The semantics roughly is that it's a workable but sub-optimal configuration. The solver should try to avoid warnings, by selecting another alternative. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/400> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #438: Cabal should warn or fail if user specifies a bad configuration flag
by Hackage 17 Jan '09

17 Jan '09

#438: Cabal should warn or fail if user specifies a bad configuration flag ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ----------------------------+----------------------------------------------- Let us take the example of Yi. Yi specifies a flag: {{{ flag ghcAPI Description: Enable linking with GHC API for advanced features. Default: False }}} The advanced features are nice indeed, and I wish to use them. So I configure thusly: {{{ gwern@craft:33763~/bin/yi>runhaskell Setup configure --user -fghc-api Configuring yi-0.5.3... }}} (Or perhaps I specify -fghcapi, or -fghc-API. There are a lot of quite reasonable permutations, and I suspect I have made every one of them over the past few months.) The point is, the flag is *wrong*. Completely wrong. If we turn on --verbose, we notice that {{{ Flags chosen: testing=True, hacking=False, cocoa=False, pango=False, gtk=False, vty=True, ghcapi=False }}} The user is not going to get what she requested. Worse, the user has no idea! Everything looks dandy! There is not the slightest indication that something bad has happened. Half an hour later when Yi has compiled and installed, any user trying to use the Shim.* modules in their yi.hs is in for an unpleasant surprise. So the basic point here is: if the user specifies a flag, and the flag doesn't match any flags in the cabal file, *something* is wrong. Either the cabal file is damaged in someway, or the user mistyped. I think an error would be perfectly reasonable here, in the same way that missing fields is a reasonable reason for erroring out; but at a minimum a warning is warranted. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/438> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #432: cabal-install patches for HTTP 4000.0.0
by Hackage 17 Jan '09

17 Jan '09

#432: cabal-install patches for HTTP 4000.0.0 ---------------------------------+------------------------------------------ Reporter: Bart Massey | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ I noticed that the constraints on the packages for cabal-install required some pretty old stuff. Rather than go there, I decided to loosen the constraints and see what happened. The current version of Cabal (1.7) and zlib (0.5.0.0) seem to work fine. Some patches were required to get current HTTP (4000.0.0) to work. I attach these patches in case anyone cares. I have done no testing of these patches other than trying a few simple cabal commands. They seemed to work. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/432> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2