November 2008 - cabal-devel

[Hackage] #289: symlink binaries into ~/bin
by Hackage 23 Apr '09

23 Apr '09

#289: symlink binaries into ~/bin ---------------------------------+------------------------------------------ Reporter: duncan | 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: | ---------------------------------+------------------------------------------ Currently cabal-install uses `--prefix=$HOME/.cabal` and does not specify `--bindir` so we use `$HOME/.cabal/bin` as the bindir. Obviously this is not on the `$PATH` by default. It would be trivial to specify `--bindir=$HOME/bin` however the worry is that we would be stomping on programs that the user has already installed there. One solution is to continue to install into `$HOME/.cabal/bin` and then to make symlinks into `$HOME/bin` if the target name does not already exist. If the name does exist we could give a warning and let the user sort it out. Of course we need to be able to overwrite our own symlinks. We know it's a symlink we're allowed to overwrite if it links into `$HOME/.cabal/bin`. It would be nice to install into `$HOME/.cabal/bin` using versioned binary names (Cabal supports that now) and symlink the generic name into `$HOME/bin`. We can discover the names of the binary we're installing by checking the executable names in the `PackageDescription`. Of course this has to be an optional feature since not everyone wants it and there are no symlinks on windows. I'd imagine we'd have it in the `~/.cabal/config` file something like: {{{ prefix: $HOME/.cabal -- bindir: $HOME/.cabal/bin symlink-bindir: $HOME/bin }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/289> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 17

[Hackage] #266: cabal haddock plus cpp preprocessing with relative #include files
by Hackage 17 Mar '09

17 Mar '09

#266: cabal haddock plus cpp preprocessing with relative #include files ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic Bug 2: cabal haddock fails $ cabal haddock Preprocessing library homeomorphic-0.1... Running Haddock for homeomorphic-0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: base-3.0.1.0, QuickCheck-1.1.0.0, mtl-1.1.0.0, containers-0.1.0.1 dist/build/tmp/Data/Homeomorphic/Hash1.hs:4:0: Include/Hash.hs: No such file or directory This one may well be my fault, if some extra magic is required for the haddock with CPP, but not the building - but that seems weird, if there is enough info to build the file, surely there is enough info to haddock it Duncan says: Right, there is no such guarantee at the moment. That's because ghc --make can find things by import chasing where Cabal needs more stuff specified explicitly. One day when Cabal does the import chasing they'll be consistent. In this case though it doesn't look like on of those problems. It seems to be because for haddock we're copying files to dist/ and then running cpp on them. That means of course that relative #includes do not work. It's not entirely clear to me why we are copying them before running cpp and not just running cpp on the files from their original locations. Please file a ticket for this one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/266> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #188: file extensions
by Hackage 16 Mar '09

16 Mar '09

#188: file extensions --------------------------+------------------------------------------------- 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: Linux | --------------------------+------------------------------------------------- GHC ignores Objective C sources unless -x c is passed to it on the command line before the source files. As far as I could tell there is no way to pass that option to GHC through Cabal so no .m files ever get built (well.. not completely true - setting ghc-options works but that breaks compilation of Haskell code). One way to get this to work would be to just add some extra code in Cabal to automatically pass -x c for .m files. This is probably a bad idea as someone might want or need to compile files using some other extension at some point. Another option is add some way of specifying compile options on a per-file (or group of files) basis: setting ghc-options to -x c just for one set of files. Still very limited but it's an improvement over the first option. Third option I can think of is to add a way of specifying compiler/extension pairs in Cabal so given compilers are automatically used to compile files with corresponding extensions. Depending on how much time I have I might look into adding this functionality myself but would like some feedback on which approach to take. Otherwise I might have to stick with autotools and ignore Cabal until it gets a bit more mature and flexible. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/188> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #381: broken link cabal user guide
by Hackage 11 Mar '09

11 Mar '09

#381: broken link cabal user guide ----------------------------------+----------------------------------------- Reporter: luntain | Owner: Type: defect | Status: new Priority: low | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.3 Platform: | ----------------------------------+----------------------------------------- http://www.haskell.org/cabal/release/latest/doc/users-guide/builders.html #setup-test contains a broken link with label: Distribution.Simple the fragment which contais the link reads: "See Distribution.Simple for information about creating hooks and using defaultMainWithHooks." -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/381> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #380: Ability to blacklist packages that are on hackage
by Hackage 11 Mar '09

11 Mar '09

#380: Ability to blacklist packages that are on hackage ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: wishlist blacklist Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Sometimes there are packages on hackage that I don't want to install, perhaps ever. Maybe there is a buggy release I'm trying to avoid, or something of that nature. So, my proposal is a user defined blacklist. I think the version specification could work just like that of a .cabal file. I also think cabal should tell you when it skips a dependency due to blacklisting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/380> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #309: cabal install should recognize if package was already configured
by Hackage 09 Mar '09

09 Mar '09

#309: cabal install should recognize if package was already configured ---------------------------------+------------------------------------------ Reporter: bfr | 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: | ---------------------------------+------------------------------------------ If I first configure an unpacked package inside its source directory cabal configure --prefix=/my/path --flags=whatever and then afterwards do cabal install then the configure options I gave before are not recognized by the 'cabal install'. Instead, 'cabal install' without a package name argument should inspect whether the package is already configured and use whatever options have been set. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/309> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #294: Setup build should call Setup configure, if necessary
by Hackage 09 Mar '09

09 Mar '09

#294: Setup build should call Setup configure, if necessary ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- If you change the Cabal description file of your project, you need to reconfigure it by calling ''Setup.lhs config'' (assuming that your Setup program is called ''Setup.lhs''). Since most editors don't know anything about Cabal, that requires you to have a shell open and type the command in question manually, which can get quite annoying, if you reconfigure often. ''Setup.lhs build'' recognizes the case, when the configuration has changed and dies with an error. It would be very useful, if it would call the ''configure'' command automatically instead, for example with the last used flags, or with a default set of flags configured in the description file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/294> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #335: GHC_PACKAGE_PATH disrespected
by Hackage 09 Mar '09

09 Mar '09

#335: GHC_PACKAGE_PATH disrespected ----------------------------+----------------------------------------------- Reporter: cjs | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Other Unix | ----------------------------+----------------------------------------------- Looks like cabal doesn't even use GHC_PACKAGE_PATH at all. {{{ $ unset GHC_PACKAGE_PATH $ ghc-pkg list binary /usr/pkg/lib/ghc-6.8.3/package.conf: $ export GHC_PACKAGE_PATH=/my/package.conf:/usr/pkg/lib/ghc-6.8.3/package.conf $ ghc-pkg list binary /usr/pkg/lib/ghc-6.8.3/package.conf: /my/package.conf: binary-0.4.1 $ runghc Setup.hs configure Configuring mypackage-1.0... Setup.hs: At least the following dependencies are missing: binary -any }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/335> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #337: --disable-split-objs has wrong help string
by Hackage 09 Mar '09

09 Mar '09

#337: --disable-split-objs has wrong help string ----------------------------+----------------------------------------------- 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.3 Platform: Mac OS | ----------------------------+----------------------------------------------- I did: $ ./Setup.lhs configure --help ... --enable-split-objs split library into smaller objects to reduce binary sizes (GHC 6.6+) --disable-split-objs split library into smaller objects to reduce binary sizes (GHC 6.6+) ... It should read: --disable-split-objs retain library as one object file (GHC 6.6+) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.3 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/337> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #346: Add a warning for synopsis being a prefix of the description
by Hackage 09 Mar '09

09 Mar '09

#346: Add a warning for synopsis being a prefix of the description ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Many packages provide useless descriptions, just repeating the synopsis. Three (all from different authors, and only looking at those with "string" as a substring of the name!) include stringtable-atom, bytestring-csv and packedstring. Suggestion: Give a warning when the synposis is a prefix of the description. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/346> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5