August 2008 - cabal-devel

[Hackage] #316: on Windows, include paths with spaces not properly passed to c2hs
by Hackage 26 Jan '09

26 Jan '09

#316: on Windows, include paths with spaces not properly passed to c2hs ----------------------------+----------------------------------------------- Reporter: jwlato | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.4.0 Severity: normal | Keywords: include-dirs, c2hs Difficulty: normal | Ghcversion: 6.8.3 Platform: Windows | ----------------------------+----------------------------------------------- On windows, path names with spaces aren't passed to build tools properly. In a new project, with a source file Test.chs and a cabal file with (boilerplate excluded) {{{ #!c exposed-modules: Test build-tools: c2hs include-dirs: "C:\\Program Files\\include" }}} then attempting "runhaskell Setup.lhs build -v" indicates that the following is executed: {{{ #!c c:\Program Files\Haskell\bin\c2hs.exe --include=dist\build --cppopts=-D__GLASGOW_HASKELL__=608 --cppopts=-IC:\Program Files\include --output-dir=dist\build --output=Test.hs Test.chs }}} This command fails because c2hs interprets Files\include as a filename to process. The -IC:\Program Files ... should be quoted to preserve the space in the path. I have attached a test.cabal and Test.chs file that demonstrate the problem. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/316> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #200: Feature request: Simplify the profiling process
by Hackage 25 Jan '09

25 Jan '09

#200: Feature request: Simplify the profiling process ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- Add Setup.(l)hs options that: 1) tells ghc to make a profiling library; 2) tells ghc to make a profiling executable 3) pass on the (a) -auto or (b) -auto-all option 4) Let you do (1)-(2)-(3a) or (1)-(2)-(3b) with a single option, instead of three. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/200> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 10

[Hackage] #177: Include-dirs, extra-lib-dirs with spaces doesn't work under Windows
by Hackage 22 Jan '09

22 Jan '09

#177: Include-dirs, extra-lib-dirs with spaces doesn't work under Windows ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Windows | ----------------------+----------------------------------------------------- Trying to build the HDBC-PostGreSQL database driver[1] revealed some poor handling of pathames under Windows. The package requires that the paths to postgre header and libraries files be added to the .cabal file. My initial attempt was the obvious: {{{ include-dirs: C:\Program Files\PostgreSQL\8.2\include, C:\Program Files\PostgreSQL\8.2\include\server, . extra-lib-dirs: C:\Program Files\PostgreSQL\8.2\include, C:\Program Files\PostgreSQL\8.2\include\server }}} However, the package would not build. The include files "pg_config.h" and some others were not found. Using single or double quotes did not help. Finally, I moved the installation to "C:\pgsql" and updated the .cabal file: {{{ include-dirs: C:\pgsql\include, C:\pgsql\include\server, . extra-lib-dirs: C:\pgsql\lib }}} And the package built. It seems the spaces in the first path caused the problem. For reference, this it the configure output on my machine: {{{ Configuring HDBC-postgresql-1.0.1.0... configure: Dependency base-any: using base-2.1.1 configure: Dependency mtl-any: using mtl-1.0.1 configure: Dependency HDBC>=1.0.0: using HDBC-1.0.1 configure: Dependency parsec-any: using parsec-2.0 configure: Using install prefix: C:\Program Files configure: Binaries installed in: C:\Program Files\Haskell\bin configure: Libraries installed in: C:\Program Files\Haskell\HDBC- postgresql-1.0.1.0\ghc-6.6.1 configure: Private binaries installed in: C:\Program Files\HDBC- postgresql-1.0.1.0 configure: Data files installed in: C:\Program Files\Common Files\HDBC- postgresql-1.0.1.0 configure: Using compiler: c:\ghc\ghc-6.6.1\bin\ghc.exe configure: Compiler flavor: GHC configure: Compiler version: 6.6.1 configure: Using package tool: c:\ghc\ghc-6.6.1\bin\ghc-pkg.exe configure: Using ar found on system at: c:\ghc\ghc-6.6.1\bin\ar.exe configure: Using haddock found on system at: C:\haddock\haddock-0.8\haddock.exe configure: No pfesetup found configure: Using ranlib found on system at: c:\MinGW\bin\ranlib.exe configure: Using runghc found on system at: c:\ghc\ghc-6.6.1\bin\runghc.exe configure: Using runhugs found on system at: C:\Program Files\WinHugs\runhugs.exe configure: No happy found configure: No alex found configure: Using hsc2hs: c:\ghc\ghc-6.6.1\bin\hsc2hs.exe configure: No c2hs found configure: No cpphs found configure: No greencard found }}} Feel free to email me at jgbailey AT gmail DOT com for more info. [1] Version 1.0.1.0 available at http://hackage.haskell.org/cgi-bin /hackage-scripts/package/HDBC-postgresql-1.0.1.0. HDBC is also required. I used 1.0.1, available at http://hackage.haskell.org/cgi-bin/hackage- scripts/package/HDBC-1.0.1. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/177> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 10

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

21 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 20 Jan '09

20 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

[Hackage] #342: Allow automatic resolving of conditionals on more than just build-depends
by Hackage 07 Jan '09

07 Jan '09

#342: Allow automatic resolving of conditionals on more than just build-depends -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- We have several classes of dependency that we can express in .cabal files. The most obvious is other Haskell packages via the `build-depends` field. The others are: * C libs (`extra-libraries`) * C headers (`includes`) * other build tools (`build-tools`) * pkg-config packages (`pkgconfig-depends`) * MacOS X frameworks (`frameworks`) And we may end up with more, like Windows assemblies. If we know (by domain-specific means) what dependencies are available then we should be able to automatically resolve flag conditions that depend on them. So each one is it's own namespace and they have different representations of keys. Most use a name and some a version too. Currently `finalizePackageDescription` takes a `Maybe (PackageSet pkg)` as a way of testing if deps are available. We should generalise this to a dep testing function (which is essentially what `finalizePackageDescription` turns it into internally) on a type that has alternatives for each of the dependency namespaces. If we only had to generalise it for package constraints we might go for `Dependency -> [PackageId]` but how should we do it when we have multiple namespaces and some require version constraints and others do not. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/342> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #327: should require minimum c2hs version of 0.15
by Hackage 22 Dec '08

22 Dec '08

#327: should require minimum c2hs version of 0.15 ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Cabal does not work with c2hs older than 0.15. With older c2hs versions the .hs file ends up in the wrong location in the build tree. If we find that c2hs is needed for the build then we should check that it meets this minimum version. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/327> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #340: Deprecate RecordPuns and translate NamedFieldPuns for older ghc
by Hackage 16 Dec '08

16 Dec '08

#340: Deprecate RecordPuns and translate NamedFieldPuns for older ghc ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.6 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The `RecordPuns` extension was accidentally added. In ghc-6.10 it will be deprecated and done as an alias for `NamedFieldPuns`. See: http://hackage.haskell.org/trac/ghc/ticket/2320 That means people will use `NamedFieldPuns` instead which will then not work with older ghc. Cabal should encourage users to switch to `NamedFieldPuns` but should translate this into `RecordPuns` when calling older ghc versions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/340> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1