November 2008 - cabal-devel

[Hackage] #371: cabal-install can break installed packages by rebuilding dependents
by Hackage 09 Mar '09

09 Mar '09

#371: cabal-install can break installed packages by rebuilding dependents ---------------------------------+------------------------------------------ Reporter: duncan | 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: | ---------------------------------+------------------------------------------ Install plans sometime involve rebuilding a package. This is not a safe operation however. Rebuilding a package can and does change its ABI. The ideal solution is to use a persistent package store like nix. That would mean we do not replace any installed package, just add new instances. In the mean time however one solution would be to extend an install plan the re-installs a package such that it rebuilds all reverse dependencies too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/371> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #386: Cabal changelog is not in user's guide
by Hackage 09 Mar '09

09 Mar '09

#386: Cabal changelog is not in user's guide ----------------------------+----------------------------------------------- Reporter: Deewiant | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ----------------------------+----------------------------------------------- The Cabal user's guide doesn't contain the changelog. This means, for instance, that one can't view it in the offline documentation distributed with GHC. It's also not directly linked from http://www.haskell.org/cabal/, making it altogether a bit better hidden than it should be. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/386> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #303: cabal clean: Error while removing dist/: dist/setup: removeDirectory: unsatisified constraints (Directory not empty)
by Hackage 09 Mar '09

09 Mar '09

#303: cabal clean: Error while removing dist/: dist/setup: removeDirectory: unsatisified constraints (Directory not empty) ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- cabal clean has a problem on Windows and Unix with NFS that causes it to fail when using a custom `Setup.hs`. The problem is that we compile `Setup.hs` to `dist/setup/setup`, and then invoke `dist/setup/setup clean` which is supposed to remove the whole of the `dist` tree, including the running binary. This causes problems on Windows where running binaries can't be deleted, and also on NFS where deleting the running binary leaves a `.nfs` file behind, preventing the parent directory from being deleted. {{{ > cabal clean -v Creating dist/setup (and its parents) dist/setup/setup clean --verbose=2 --distpref=dist cleaning... Error while removing dist/: dist/setup: removeDirectory: unsatisified constraints (Directory not empty) > ls -lr dist total 36 -rw-rw-r-- 1 simonmar GHC 13069 2008-06-23 11:34 setup-config drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:34 setup/ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 build/ ~/darcs/ghc-paths > ls -lra dist total 52 -rw-rw-r-- 1 simonmar GHC 13069 2008-06-23 11:34 setup-config drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:34 setup/ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 build/ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ../ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:34 ./ ~/darcs/ghc-paths > ls -lRa dist dist: total 52 drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:34 ./ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ../ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 build/ drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:34 setup/ -rw-rw-r-- 1 simonmar GHC 13069 2008-06-23 11:34 setup-config dist/build: total 52 drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ./ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:34 ../ drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:32 autogen/ drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:32 GHC/ -rw-rw-r-- 1 simonmar GHC 3657 2008-06-23 11:32 HSghc-paths-0.1.o -rw-rw-r-- 1 simonmar GHC 4404 2008-06-23 11:32 libHSghc-paths-0.1.a dist/build/autogen: total 24 drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:32 ./ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ../ -rw------- 1 simonmar GHC 990 2008-06-23 11:32 Paths_ghc_paths.hs dist/build/GHC: total 32 drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:32 ./ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:32 ../ -rw-rw-r-- 1 simonmar GHC 895 2008-06-23 11:32 Paths.hi -rw-rw-r-- 1 simonmar GHC 3824 2008-06-23 11:32 Paths.o dist/setup: total 16 drwxrwxr-x 2 simonmar GHC 4096 2008-06-23 11:34 ./ drwxrwxr-x 4 simonmar GHC 4096 2008-06-23 11:34 ../ }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/303> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

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