July 2008 - cabal-devel

[Hackage] #236: Installed package config refers to nonexisting haddock interface and html files
by Hackage 04 Feb '09

04 Feb '09

#236: Installed package config refers to nonexisting haddock interface and html files ----------------------------+----------------------------------------------- Reporter: kolmodin | 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: | ----------------------------+----------------------------------------------- Cabal generates the {{{haddock-interfaces}}} and {{{haddock-html}}} package fields even if the haddock documentation is not built nor installed. Instead of assuming haddock is used, it should add the fields iff needed upon register (install = copy + register), where enough information should be available to make a more clever installation. Example {{{ghc-pkg describe binary}}} built without haddock: {{{ name: binary version: 0.4.1 license: BSD3 copyright: maintainer: Lennart Kolmodin, Don Stewart <dons(a)galois.com> stability: provisional homepage: http://www.cse.unsw.edu.au/~dons/binary.html package-url: description: Efficient, pure binary serialisation using lazy ByteStrings. Haskell values may be encoded to and form binary formats, written to disk as binary, or sent over the network. Serialisation speeds of over 1 G\/sec have been observed, so this library should be suitable for high performance scenarios. category: Data, Parsing author: Lennart Kolmodin <kolmodin(a)dtek.chalmers.se> exposed: True exposed-modules: Data.Binary Data.Binary.Put Data.Binary.Get Data.Binary.Builder hidden-modules: import-dirs: /usr/lib/binary-0.4.1/ghc-6.8.2 library-dirs: /usr/lib/binary-0.4.1/ghc-6.8.2 hs-libraries: HSbinary-0.4.1 extra-libraries: extra-ghci-libraries: include-dirs: includes: depends: base-3.0.1.0 bytestring-0.9.0.4 base-3.0.1.0 containers-0.1.0.1 array-0.1.0.0 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: /usr/share/doc/binary-0.4.1/html/binary.haddock haddock-html: /usr/share/doc/binary-0.4.1/html }}} Both {{{/usr/share/doc/binary-0.4.1/html/binary.haddock}}} and {{{/usr/share/doc/binary-0.4.1/html}}} are (rightfully) missing in the installation. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/236> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[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] #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] #203: Find out what we can learn from ruby gems
by Hackage 15 Dec '08

15 Dec '08

#203: Find out what we can learn from ruby gems ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: misc | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------+------------------------------------------------------ [http://rubygems.org/ Ruby Gems] is superficially a similar system for Ruby as Cabal + cabal-install + HackageDB is for Haskell. This task is to do some research to compare two systems to find out what lessons we can learn from Ruby Gems. The findings should be recorded on the [wiki:RubyGems] wiki page -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/203> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #209: Implement "package()" configurations predicate
by Hackage 08 Nov '08

08 Nov '08

#209: Implement "package()" configurations predicate ----------------------------+----------------------------------------------- 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.2 Platform: Linux | ----------------------------+----------------------------------------------- We often have to write things like: {{{ flag splitBase description: Choose the new smaller, split-up base package. library if flag(splitBase) build-depends: base >= 3, containers else build-depends: base < 3 }}} Which is verbose and annoying. It would be nicer to say: {{{ library build-depends: base if package(base >= 3) build-depends: containers }}} This is syntactic sugar only. It translates into the existing constructs so no new behaviour is being introduced. It would translate into: {{{ flag _1 library build-depends: base if flag(_1) build-depends: base >= 3 build-depends: containers else build-depends: base < 3 }}} It is described in more detail in this thread: http://www.haskell.org/pipermail/cabal-devel/2007-October/001189.html http://www.haskell.org/pipermail/cabal-devel/2007-November/001336.html -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/209> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #308: provide hierarchical haddock for each package
by Hackage 14 Oct '08

14 Oct '08

#308: provide hierarchical haddock for each package --------------------------------+------------------------------------------- Reporter: EricKow | Owner: Type: task | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- The primary haddock documentation for some packages seems to be on hackage. But on hackage, you see separate links for each module within the package, not a nice hiearchical listing like the one on http://www.haskell.org/ghc/docs/latest/html/libraries/ It would be nice if each package had its own mini-hierarchy -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/308> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #218: Data-files have no way of being installed conditionally
by Hackage 09 Oct '08

09 Oct '08

#218: Data-files have no way of being installed conditionally ----------------------------+----------------------------------------------- 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: Linux | ----------------------------+----------------------------------------------- Using cabal-1.2.3.0 and Yi, I have the following problem. For the Mac OS X Cocoa port, it has an icon which is a PDF file containing a rendered version of the Yi SVG logo, and which gets installed with it. Installing the PDF only makes sense if you are on a Mac (indeed, the PDF seems to be corrupt if you try to view it with, say, Xpdf). Right now, the yi.cabal file just reads: cabal-Version: == 1.2.3.0 tested-with: GHC==6.8.2 build-type: Custom data-files: art/yi+lambda-fat.pdf -- FIXME: Install Cocoa icon only when Cocoa configured That is, the PDF is always installed. Now, my first attempt was to read the Cabal manual and realize that the obvious solution was to just stick the data-files: field under a flag or conditional - just like the yi.cabal already does for build-depends, ghc-options, buildable, etc. But this doesn't work! Yi will still compile and build, but Cabal says: Warning: Unknown fields: data-files (line 101) Fields allowed in this section: executable, main-is, buildable, build-tools, cpp-options, cc-options, ld-options, pkgconfig-depends, frameworks, c-sources, extensions, extra-libraries, extra-lib-dirs, includes, install-includes, include-dirs, hs-source-dirs, other-modules, ghc-prof-options, ghc-shared-options, ghc-options, hugs-options, nhc98-options, jhc-options The error tells me that the conditional didn't take: gwern@localhost:1023~/bin/yi_0>locate fat|grep lambda|grep .pdf [ 4:31PM] /home/gwern/bin/yi/_darcs/pristine/art/yi+lambda-fat.pdf /home/gwern/bin/yi/art/yi+lambda-fat.pdf /home/gwern/bin/share/yi-0.3/art/yi+lambda-fat.pdf gwern@localhost:1024~/bin/yi_0> (Even though I am on Linux, and the Cocoa flag is emphatically set to False.) -- Anyway, given that what I want to do is sensible, that nowhere in the docs I've been able to find or on #haskell mentions any non-hacky solution, and that it's already supported by Cabal for other kinds of files, I think this is a pretty reasonable feature request. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/218> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4