- cabal-devel - Haskell.org

Cabal --builddir
by Neil Mitchell 25 Feb '09

25 Feb '09

Hi, Cabal documents itself as having a --builddir command to change the placement of dist stuff, which is fantastic. However, running with GHC 6.8.3, Cabal 1.6.0.2, I get: cabal build --builddir=../../../_make/Tools/ext/haddock-0.9/dist setup.exe: Unrecognised flags: --builddir=../../../_make/Tools/ext/haddock-0.9/dist i.e. cabal accepts the --builddir command, but the setup that cabal builds doesn't. Why? Thanks Neil

4 9

patch applied (cabal): Allow --with-ghc to be specified when running Cabal
by Ian Lynagh 25 Feb '09

25 Feb '09

Wed Feb 25 09:22:49 PST 2009 Ian Lynagh <igloo(a)earth.li> * Allow --with-ghc to be specified when running Cabal M ./Distribution/Simple/Setup.hs -2 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090225172249-3fd76-0318f921…

1 0

[Hackage] #507: display available flags based on the .cabal file
by Hackage 25 Feb '09

25 Feb '09

#507: display available flags based on the .cabal file ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently cabal configure --help displays only the help for the configure command in general. Often I'd like to say what flags are available for the package in question. Currently the only way to do this seems to be to actually look at the .cabal file in question. Something a bit like: ./configure --help which shows you the generic flags like --prefix but also --enable-glade (for example). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/507> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #508: user guide should document new fields with the version of Cabal they appeared in
by Hackage 25 Feb '09

25 Feb '09

#508: user guide should document new fields with the version of Cabal they appeared in ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- It would be nice if the user guide specified in which Cabal version a field was first introduced. This would help package authors work out compatibility. With this documented we should also check that `cabal check` gives the same advice. That is if a package uses a field that is new in version 1.2 say, that `cabal check` warns if the `cabal-version: >=x.y` number is not high enough. It should only be a warning not an error because older Cabal versions only warn about unknown fields. While we're at it, we should document in the user guide that unknown fields give a warning, but should not cause a parse error. This lets people use new non-essential informational fields without having to absolutely require a later Cabal version. Probably a section on version compatibility is wanted. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/508> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #506: Extensions field not being used
by Hackage 24 Feb '09

24 Feb '09

#506: Extensions field not being used ----------------------------+----------------------------------------------- Reporter: fasta | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.10.1 Platform: | ----------------------------+----------------------------------------------- ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I use the extensions field and I specified NoImplicitPrelude as its value. The problem is that this is ignored in a module without any LANGUAGE pragma (but I believe it also doesn't work with a LANGUAGE pragma). I expect that the extensions for a module compiled via Cabal are the union of those specified in the extensions field in the Cabal file and those of the corresponding Module.hs file as specified with the LANGUAGE pragma. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/506> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): fix imports for non-GHC
by Ross Paterson 21 Feb '09

21 Feb '09

Sat Feb 21 08:49:39 PST 2009 Ross Paterson <ross(a)soi.city.ac.uk> * fix imports for non-GHC Ignore-this: 12756e3863e312352d5f6c69bba63b92 M ./Distribution/Compat/TempFile.hs -1 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090221164939-b47d3-5a6afd10…

1 0

Hackage page format
by Gwern Branwen 21 Feb '09

21 Feb '09

Would it be possible for a small tweak to be made to Hackage pages? eg on <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hback>, I'd like it if the format was not "hback: N-back memory game" but rather something like "hback \n N-back memory game". A small change, but it'd make it easier to copy-paste for me. If you look, that's the only actual place in the entire page where the package name is. As it is, I often copy-paste and wind up with a colon anyway. -- gwern

1 0

darcs patch: Add --build-to option for controlling the amount of wo...
by hamish＠firestream.co.uk 21 Feb '09

21 Feb '09

Sat Feb 21 22:05:31 NZDT 2009 hamish(a)firestream.co.uk * Add --build-to option for controlling the amount of work done by build This is useful for validating code during while it is being edited. --build-to=Check will only look for errors in the files source files (not implemented yet). --build-to=Compile will produce object files but not link (only fully works for GHC). The default (--build-to=Full) does a full build as normal.

1 0

Adding a world file to cabal-install
by Peter Robinson 20 Feb '09

20 Feb '09

Hello, I recently upgraded GHC on one of my machines and therefore had to reinstall all installed packages. Granted, cabal-install makes this a lot easier nowadays, but I saw that there's a ticket [1] for adding a "world" file (speaking in Gentoo terminology) that records all user requested packages, so I gave that a try. You can find a patch for the Head branch that adds preliminary support here: http://darcs.monoid.at/cabal-install/ Basically the patch adds Distribution.Client.World that provides an /insert/, /delete/, and /getContents/ interface. /World.insert/ is called from Distribution.Client.Install upon successful build. What's currently missing is the implementation of a cabal command that rebuilds the package list from ~/.cabal/world (or some other location set by the currently also missing configuration options). 1. The world file only contains the list of package names and versions as requested by the user. I suppose that's all that's needed for rebuilding, right? 2. How should that command look like? Something like: # cabal install --world Suggestions and advice welcome! Cheers, Peter [1] http://hackage.haskell.org/trac/hackage/ticket/199

3 7

[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