February 2008 - cabal-devel

[Hackage] #231: "buildable: False" should fail the current configuration
by Hackage 27 Apr '09

27 Apr '09

#231: "buildable: False" should fail the current configuration ----------------------------+----------------------------------------------- Reporter: duncan | 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: | ----------------------------+----------------------------------------------- Currently resolving configurations does not take account of the `buildable` field. It should act rather like `build-depends: non- existant`, though with a different error message. If possible the error message should relate to the guard condition expression (the conjunction if there are several nested guards). At the moment it is not considered at all and we don't notice that the package cannot be built until the build step, rather than the configure step. One problem is that it's not clear if `buildable: False` is always fatal. People sometimes do that for test executables that are not supposed to be installed. So what should the behaviour be? The lib or only exe failing to configure must be an error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/231> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #188: file extensions
by Hackage 16 Mar '09

16 Mar '09

#188: file extensions --------------------------+------------------------------------------------- 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: Linux | --------------------------+------------------------------------------------- GHC ignores Objective C sources unless -x c is passed to it on the command line before the source files. As far as I could tell there is no way to pass that option to GHC through Cabal so no .m files ever get built (well.. not completely true - setting ghc-options works but that breaks compilation of Haskell code). One way to get this to work would be to just add some extra code in Cabal to automatically pass -x c for .m files. This is probably a bad idea as someone might want or need to compile files using some other extension at some point. Another option is add some way of specifying compile options on a per-file (or group of files) basis: setting ghc-options to -x c just for one set of files. Still very limited but it's an improvement over the first option. Third option I can think of is to add a way of specifying compiler/extension pairs in Cabal so given compilers are automatically used to compile files with corresponding extensions. Depending on how much time I have I might look into adding this functionality myself but would like some feedback on which approach to take. Otherwise I might have to stick with autotools and ignore Cabal until it gets a bit more mature and flexible. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/188> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #238: haddock2 is not passed -D__HADDOCK__ or cpp-options
by Hackage 03 Mar '09

03 Mar '09

#238: haddock2 is not passed -D__HADDOCK__ or cpp-options ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | 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: | ----------------------------------+----------------------------------------- With haddock-1, Cabal invokes cpp, passing it ARCH and OS defines, -D__HADDOCK__ and the contents of cpp-options. However haddock-2 invokes cpp itself via the GHC API, which passes this cpp the ARCH and OS defines, but it doesn't get the others. It might also be a good idea to give __HADDOCK__ a numeric value, because GHC extensions need not be hidden from the new one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/238> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

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