May 2008 - cabal-devel

[Hackage] #189: Handle framework paths (-F) in Cabal
by Hackage 03 Mar '09

03 Mar '09

#189: Handle framework paths (-F) in Cabal --------------------------+------------------------------------------------- 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: Mac OS | --------------------------+------------------------------------------------- There's been some discussion on the GHC trac ([http://hackage.haskell.org/trac/ghc/ticket/1931 1931], [http://hackage.haskell.org/trac/ghc/ticket/1798 1798], [http://hackage.haskell.org/trac/ghc/ticket/1395 1395]) about adding framework search paths (gcc's `-F` flag, and ghc's `-framework-path` flag). Currently Cabal handles `-framework`, but not `-framework-path`. I propose the following behavior for Cabal: 1. Add a `framework-path:` field which will pass `-framework-path` to `ghc` and `-F` to `gcc`, `hsc2hs`, et. al. 2. Always add `-F$HOME/Library/Frameworks` as an argument to the above programs (regardless of any `framework-path` entries). I believe `#1` to be uncontroversial. My reasoning for `#2` is the following: - `$HOME/Library/Frameworks` is the standard location to put frameworks if you do not have administrative access. - Without it, `readline.cabal` (e.g.) would need {{{ framework-path: /Users/judah/Library/Frameworks }}} which is not portable between machines. Finally, note that these flags only affect build behavior, not runtime loading of libraries (which searches `$HOME/Library/Frameworks` by default). See [http://hackage.haskell.org/trac/ghc/wiki/OSXFrameworks OSXFrameworks] for more info. -Judah -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/189> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 13

[Hackage] #206: cabal-install should be able to generate haddock docs
by Hackage 03 Mar '09

03 Mar '09

#206: cabal-install should be able to generate haddock docs ---------------------------------+------------------------------------------ Reporter: guest | 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: Linux | ---------------------------------+------------------------------------------ It would be really cool if it could keep an index up to date as well. (I like to have offline docs for all installed packages, but it's a headache to keep current.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/206> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 16

[Hackage] #227: Cabal-install does not track down build-tools: dependencies?
by Hackage 20 Feb '09

20 Feb '09

#227: Cabal-install does not track down build-tools: dependencies? ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ On #haskell, nelhage mentioned that one of the bugs he ran into while trying to install Yi-0.3 through cabal-install was an error which looked like this: <pre> Installing: /home/gwern/.cabal/lib/regex-posix-0.72.0.2/ghc-6.8.2/regex- posix-0.72.0.2/ghc-6.8.2 Registering regex-posix-0.72.0.2... Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. 'yi-0.3' is cached. [1 of 1] Compiling Main ( Setup.hs, dist/setup/Main.o ) Linking dist/setup/setup ... Configuring yi-0.3... setup: alex version >=2.0.1&&<3 is required but it could not be found. </pre> That is, the dependency on Alex (a version which satisfied >=2.0.1&&<3) was not met. Perfectly sensible as he did not have Alex installed. Puzzled, he did a 'cabal install alex', which worked, and then re-started. (I guess he had his GHC installed locally?). He and I were puzzled, because cabal-install is supposed/usually does track down dependencies. Is build-tools excluded for a reason, or was it just accidentally omitted from dependency-tracking? If the latter, I think this is a bit of a bug. (I use Cabal-1.2.3.0, btw, and the error message above was my reproduction of Nelhage's problem. I had to uninstall Alex from my system, but that did the trick, and reinstalling bypassed the issue just fine - which is why I hadn't seen it before.) -- gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/227> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #262: Check for required C libraries during configure
by Hackage 18 Feb '09

18 Feb '09

#262: Check for required C libraries during configure ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- Cabal should check for required C libraries and other non-Haskell dependencies at the configure stage, rather than just waiting for the linker to fail with an obscure error message during the build stage. Error messages should be helpful for the typical Cabal user, who should not be assumed to know anything about C libraries or linking. That is not so simple. For example: The haddock package current requires the C libraries for readline, due to its dependency on the GHC API. If that library is missing, the user should have some way of figuring out how do the right thing on the given platform - for most Linux distros, install the readline-dev package (as opposed to just readline), for Mac OS X download the GNUreadline framework from the GHC website and drag it into the appropriate Frameworks folder depending on whether this is Tiger and below or Leopard and above, etc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/262> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 16

[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] #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