October 2008 - cabal-devel

[Hackage] #290: Cabal does some work behind the back of hooks
by Hackage 07 Mar '09

07 Mar '09

#290: Cabal does some work behind the back of hooks ----------------------------+----------------------------------------------- Reporter: igloo | 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 does some work behind the back of hooks, e.g. with `q.cabal`: {{{ name: q version: 1 exposed-modules: Bar build-type: Custom }}} and `Setup.hs`: {{{ module Main (main) where import Distribution.Simple import Distribution.Simple.Setup import System.Cmd main :: IO () main = defaultMainWithHooks myHooks myHooks :: UserHooks myHooks = simpleUserHooks { confHook = \x flags -> do let flags' = flags { configDistPref = Flag "foo" } lbi <- (confHook simpleUserHooks) x flags' system "ls" return lbi, postConf = \args flags pd lbi -> do system "ls" let flags' = flags { configDistPref = Flag "foo" } (postConf simpleUserHooks) args flags' pd lbi return () } }}} a `dist` directory magically appears between the configure hook and the postconf hook: {{{ $ ./Setup configure Configuring q-1... Setup Setup.hi Setup.hs Setup.o foo q.cabal Setup Setup.hi Setup.hs Setup.o dist foo q.cabal $ ls -l dist -rw-r--r-- 1 ian ian 6411 Jun 8 12:02 setup-config }}} The reason I want to do this is so that `Setup.hs` can take care of building itself in multiple ways, using different dist directories. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/290> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #263: Multiple compilers of the same version confuse Cabal
by Hackage 07 Mar '09

07 Mar '09

#263: Multiple compilers of the same version confuse Cabal ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- It often happens that two or more copies of the same version of the same compiler are installed on a system. For example, the compiler can be installed with an installation package, or be built from the source tarball, or from darcs, or using MacPorts. If a package is installed for each of these copies of the compiler while allowing Cabal to use the default installation location each time, Cabal will always use the exact same folder. This leads to mayhem and anarchy. Proposed solution: Cabal should also use the base path of the compiler when it constructs the directory name for the package, not just the compiler name and version. For example: If I install a package foo-1.2.3.4 --with- compiler=/opt/local/bin/ghc-6.8.2 and the installation base path is /usr/local, then Cabal should install the package into /usr/local/foo-1.2.3.4/opt_local_ghc-6.8.2 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/263> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[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] #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] #368: The "optimization" option in ~/.cabal/config does not work
by Hackage 01 Feb '09

01 Feb '09

#368: The "optimization" option in ~/.cabal/config does not work ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.4.0.1 Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ Running cabal install $package with "optimization: True" uncommented in ~/.cabal/config results in an error: cabal: Command.optionToFieldDescr: feature not implemented -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/368> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[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