March 2010 - cabal-devel

[Hackage] #646: cabal-install does not install data-files
by Hackage 27 Mar '10

27 Mar '10

#646: cabal-install does not install data-files ---------------------------------+------------------------------------------ Reporter: StefanK | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ Installing a package with {{{ cabal clean cabal configure --user --prefix="${HOME}/opt" cabal build cabal install }}} does not copy the data-files listed in the project.cabal file to the desired destination. It does not copy them anywhere at all. I would expect them to end below something like {{{/home/sk/opt/share/project-0.1}}}, as is reported by function {{{Paths_project.getDataFileName}}}. I'll attach a toy project demonstrating this. System: {{{ sk@watarrka:~> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 sk@watarrka:~> cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/646> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): Remove an out-of-date comment
by Ian Lynagh 27 Mar '10

27 Mar '10

Fri Mar 26 06:17:52 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Remove an out-of-date comment M ./Distribution/ModuleName.hs -2

1 0

[Hackage] #649: better warning messages for why dependencies are missing / cannot be selected
by Hackage 26 Mar '10

26 Mar '10

#649: better warning messages for why dependencies are missing / cannot be selected ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The cabal-install constraint solver should be given all packages but if some are unsable (e.g. due to broken dependencies) then it should be given constraints to avoid them. That way when it finds it needed the broken package it can give a suitable error message. Consider the following (real) confusing scenario: * usual core global packages * mtl as user package * gtk etc in a local package db `ghc-pkg list --global -f local gtk` reports that gtk is installed and deps are ok. `cabal install --global --package-db=local hsclock` reports {{{ cabal: cannot configure hsclock-1.0. It requires cairo -any and gtk -any There is no available version of cairo that satisfies -any There is no available version of gtk that satisfies -any }}} How can this be? It is because when we use --global and --package-db then we are excluding the user package db. But gtk depends on mtl from the user package db. Hence Cabal detects gtk as broken. We did not notice because `ghc-pkg --global` still includes the `--user` package db. If we use `ghc- pkg --global --no-user-package-conf -f local list` then indeed gtk etc are reported as broken. The point is, cabal should tell us not that gtk isn't installed, but that it was excluded because it is broken, missing dependencies. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/649> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Gtk2hs-devel] cabalized Gtk2Hs
by Duncan Coutts 26 Mar '10

26 Mar '10

On Sat, 2010-03-13 at 18:31 +0100, Axel Simon wrote: > Dear all, > > this is a first announcement of cabal packages for Gtk2Hs. This is > meant for all those who can spare five minutes to check the packages > and to improve them. This is great Axel. I'm glad you've taken this on (and a bit sorry I never got round to it). Can you let us know what annoyances you've hit in Cabal, so we can make sure they are all filed properly in the Cabal trac and so we can prioritise them appropriately. I expect your main problems are with .chs and .chi files. Both the fact that there is no proper dependency tracking, and the fact that .chi files from one package are not installed, yet needed when processing other packages (how do you get around that btw?). Another thing that I bet is annoying is that cabal-install isn't great for building local collections of interdependent packages. One wants a feature to be able to tell cabal that there are several locally unpacked packages (ie the gtk2hs source tree, one package per subdir) and have cabal build them in order. Similarly, once you've generated tarballs for each package, cabal isn't yet able to easily be told to install a bunch of tarballs and do dep-tracking. I have plans to make cabal-install accept more notions of package, not just the local dir and package names from hackage but also specific dir(s) or specific tarballs. On the "gtk2hs-buildtools" front, that seems like a reasonably way to go. I hope we can pull the c2hs fork out of that at some point however and use the mainline c2hs (even if initially that involves putting some of the gtk2hs syntax quirks into mainline c2hs while gtk2hs migrates to the standard syntax -- or new agreed syntax). Duncan

1 0

patch applied (cabal-branches/cabal-1.8): Fix a duplicate import
by Ian Lynagh 26 Mar '10

26 Mar '10

Thu Mar 25 13:44:20 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Fix a duplicate import M ./Distribution/Simple/Register.hs -1 +1

1 0

Cabal documentation
by Henning Thielemann 26 Mar '10

26 Mar '10

I have added some suggestions about conditional compilation to https://www.haskell.org/haskellwiki/Cabal/FAQ#Conditional_compilation Maybe my suggestion about using Hs-Source-Dirs for conditional compilation can be added to http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.h… I'm confused with a paragraph from http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html "If dependencies were missing, the last flag (as by the order in which the flags were introduced in the package description) is tried with its alternative value and so on. This continues until either an assignment is found where all dependencies can be satisfied, or all possible flag assignments have been tried." I assumed that the automatic search for appropriate flag assignments is only done by cabal-install, not by Cabal.

2 1

API-tracker to check compliance with package versioning policy---advice please?
by Damon Wang 23 Mar '10

23 Mar '10

Hello everyone, I'm interested in writing the API-tracker described here http://hackage.haskell.org/trac/summer-of-code/ticket/1565 Mr. Marlow suggested I discuss it on the mailing list first. If this is the wrong list, I'm sorry, and I'd appreciate knowing where to find the correct one. This email consists of two parts: a high-level description of how I'd like to write the API-tracker, and the problems I encountered once I tried to bring that down to the level of actually writing code. I'd appreciate advice and criticism on both. >From the package versioning policy here http://www.haskell.org/haskellwiki/Package_versioning_policy it seems like the most foolproof way to validate a revised module's version number would be to diff the types of each exported symbol. There's a previous thread on this list by Laszlo Nagy suggesting that we query other services that might already have this information, but the replies seemed to be of the opinion that it would be better to have fewer dependencies. I assume if this is meant to validate submitted packages, read access to both before and after versions are guaranteed. What do people think of the overall strategy? Following the suggestion of using the existing introspection tools in GHC, I found the modInfoExports and modInfoLookupName functions. However, I'm having some trouble understanding the GHC API because http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-6.12.1/GHC.html only provides type information and sometimes a few cryptic comments. The other thing I've been trying is reading the Haddock source, because it's basically solving the same problem, right? Unfortunately, both efforts are stalling because I lack the necessary background knowledge of how GHC handles types. Is there a more verbose, newbie-friendly documentation that will answer questions like, "Suppose I have a function foo :: String -> String. How does GHC represent the type of this function?" I think http://hackage.haskell.org/trac/ghc/wiki/Commentary has the information I need to answer that question, or at least to read the GHC API reference. Unfortunately---you guessed it!---I don't know enough to understand the commentary. If all else fails, I supposed I'll just go post my questions in [beginners] or [haskell-cafe], but I'd prefer not to bother people unncessarily. In any case, thanks for your attention. I welcome any advice. Yours, Damon Wang

3 2

[Hackage] #647: Pretty printer for package descriptions is incomplete
by Hackage 21 Mar '10

21 Mar '10

#647: Pretty printer for package descriptions is incomplete ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- IDEs and other tools want to be able to parse, edit and then print out again .cabal files. The current pretty printer for the GenericPackageDescription is incomplete. The task is to complete the pretty printer so that we can correctly round trip parse/print. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/647> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #465: default global install on windows is a problem
by Hackage 21 Mar '10

21 Mar '10

#465: default global install on windows is a problem ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Windows | ----------------------------+----------------------------------------------- Lots of windows users have problems installing things globally. Some are using multi-user systems. More are using Vista where it seems that even when they are running as administrator they cannot install files in `C:\Program Files\`. We should revisit the decision to install globally and see if we cannot find a default that works better. Failing by default is bad. We may also want to try to improve the checking beforehand to check if we would have permissions to write into the target directories. If not we can fail at configure time rather than waiting until install time and failing ungracefully. This needs someone who knows and cares about windows. Particularly for the Vista aspects. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/465> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal-branches/cabal-1.8): MERGE: Fix local inplace registration for ghc-6.12
by Duncan Coutts 21 Mar '10

21 Mar '10

Sun Mar 21 04:00:00 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * MERGE: Fix local inplace registration for ghc-6.12 Version of this patch for 1.8 branch that does not change external API. M ./Distribution/Simple/Build.hs -5 +16 M ./Distribution/Simple/Configure.hs -1 +5

1 0