December 2008 - cabal-devel

[Hackage] #398: better support for static linking
by Hackage 03 Mar '09

03 Mar '09

#398: better support for static linking ----------------------------+----------------------------------------------- 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.3 Platform: | ----------------------------+----------------------------------------------- Generating statically linked binaries on different platforms requires a bit of knowledge about what flags to pass to ghc. It would be nice to just be able to `cabal configure --enable-static-executable` or something and have that pass the extra `-optl-static` and whatever ghc options are required. If it's not possible to generate static binaries it should make some attempt at explaining why. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/398> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #424: build-depends in global section in new-style .cabal files are ignored
by Hackage 03 Mar '09

03 Mar '09

#424: build-depends in global section in new-style .cabal files are ignored ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- http://hpaste.org/12669 In a .cabal file like: {{{ name: music version: 0.0 cabal-version: >= 1.2 build-type: Simple build-depends: base == 4 library exposed-modules: Music }}} which uses new-style syntax but puts the build-depends in the global section, the build-depends get ignored. It should either warn or reject this, or it should automatically propagate such global options into each buildable component. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/424> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[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] #434: Let packages opt-in to the Package Versioning Policy
by Hackage 01 Feb '09

01 Feb '09

#434: Let packages opt-in to the Package Versioning Policy ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- Package version numbers and version constraints on dependencies are proxies for API compatibility. It is hard for people to specify the dependencies correctly and we would like to improve their quality. We have the [http://haskell.org/haskellwiki/Package_versioning_policy Package versioning policy] which says how the package version number relates to API changes. What we want is a mechanism by which package authors can opt-in to the versioning policy. We should then get hackage to check that the package really is following the policy. Just as important we can use the fact that a package does follow the policy to give suggestions to package authors. For one thing we can discourage or ban upwardly open version ranges and provide a suggestion on what upper version bound to use. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/434> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[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