- cabal-devel - Haskell.org

[Hackage] #530: configuration features
by Hackage 22 Mar '09

22 Mar '09

#530: configuration features ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently Cabal has support for ''configuration flags''. This is a nice feature, but quite limited. It can only take a boolean value, and the flag must be manually set during ''Setup.hs configure''. Here I propose a more powerfull feature, that it is yet easy to use (and, hopefully, easy to implement). The idea is to add support for ''configuration features''. A configuration feature is similar to a ''configuration flag'', but with some important differences. == Example == {{{ data Feature = Bool | String }}} A feature block: {{{ Feature HAVE_URANDOM action: execute include-dirs: ... c-sources: features/urandom.c -- other possible properties, as listed in -- "Build information chapter", excluding `buildable` and -- `other-modules` -- The `action` property can have values `compile` (default) -- or `execute` }}} This means that I'm testing for a feature named ''HAVE_URANDOM'', and the testing requires to compile/build and then execute some code. == Rules == 1. If compilation fails, ''HAVE_URANDOM'' will have value ''Feature False''. If ''action'' property is ''compile'', then a successful compilation will result in ''HAVE_URANDOM'' having a value of ''Feature True''. 2. If ''action'' property is ''execute'' and the executable returns a value /= 1, then ''HAVE_URANDOM'' will have value ''Feature False''. 3. If ''action'' property is ''execute'' and executable write something on stdout, then ''HAVE_URANDOM'' will have value ''Feature string''. 4. Otherwise ''HAVE_URANDOM'' will have value ''Feature True''. This provides a small but useful subset of what can be obtained using ''autoconf'', with the advantages that it is much more declarative, integrated with Cabal and portable. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/530> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

New Cabal FAQ
by Duncan Coutts 21 Mar '09

21 Mar '09

Hi all, I should have done this ages ago but there's now a Cabal FAQ on the Cabal website: http://haskell.org/cabal/FAQ.html It's not linked in yet, I'm looking for feedback and patches. The Cabal website is now maintained in darcs so it's easy to send in contributions: darcs get http://haskell.org/cabal/ For new pages like the FAQ I've been using markdown via pandoc. If appropriate we can migrate old pages to use that too. The main Cabal home page needs some love. We should have the cabal-install download directly on the front page. We should have quick intro tutorials for using the cabal command line program to install packages. There's lots of good material in the user guide but it is not well sign-posted. Duncan

1 0

[Hackage] #528: Permissions on "cabal fetch" files too tight
by Hackage 21 Mar '09

21 Mar '09

#528: Permissions on "cabal fetch" files too tight ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ 13:54 <twb> Why has cabal seemingly ignored my umask and made files in /home/twb/.cabal/packages unreadable by the "nobody" user? 00:14 <dcoutts> ah, I think I know 00:14 <dcoutts> it's the writeFileAtomic function 00:14 <dcoutts> are you using Cabal HEAD or 1.6? 00:15 <twb> whatever cabal upgrade gave me, I think 00:15 <dcoutts> we create a temp file and rename it over the dest 00:15 <twb> Probably not HEAD 00:15 <dcoutts> but the System.Directory function to create a temp file makes it readable only by the current user 00:16 <dcoutts> file a ticket, so we don't forget -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/528> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #451: dependency not listed on the hackageDB page
by Hackage 17 Mar '09

17 Mar '09

#451: dependency not listed on the hackageDB page --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | --------------------------------+------------------------------------------- The haskeline-0.6 package uses the terminfo package by default on POSIX systems. However, the hackageDB page for haskeline does not list terminfo as a possible dependency: http://hackage.haskell.org/cgi-bin/hackage- scripts/package/haskeline-0.5.0.1 -Judah -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/451> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[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

problem in documentation generation
by Jean-Philippe Bernardy 16 Mar '09

16 Mar '09

Hi, If a library depends on the auto-generated Paths module, cabal cannot generate the documentation: eg. Preprocessing library yi-0.6.1... Preprocessing executables for yi-0.6.1... cabal: can't find source for module Paths_yi I looked for a ticket about this but could not find anything. Is there work being done about this? Is there a workaround? Thanks, JP.

1 1

[Hackage] #524: support file, directory and url targets for packages and .cabal files
by Hackage 16 Mar '09

16 Mar '09

#524: support file, directory and url targets for packages and .cabal files ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently the `cabal` program supports two ways to specify a package. One is implicitly to look in the current directory for a .cabal file. The other is a package name (actually a dependency) which we look for in the current set of repositories. We can imagine adding more. We could: * specify the file name of a .cabal file, eg to target an unpacked package in another directory * specify the directory name and look in that directory for a .cabal file * specify the file name or url of a `.tar.gz` package For example: {{{ cabal list ../some/other/dir/ cabal info http://code.haskell.org/xmonad/xmonad.cabal cabal install http://haskell.org/cabal/dev/Cabal-1.7.2.tar.gz cabal install ./demo/ }}} The case `cabal info http://code.haskell.org/xmonad/xmonad.cabal` is very much like the `lscabal` program that was uploaded to hackage recently so apparently it is useful. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/524> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-install): Clarify the instructions in the README and bootstrap.sh
by Duncan Coutts 15 Mar '09

15 Mar '09

Sun Mar 15 05:54:07 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Clarify the instructions in the README and bootstrap.sh Addresses the complaint in ticket #523. M ./README -7 +27 M ./bootstrap.sh -4 +8 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090315125407-adfee-…

1 0

[Hackage] #523: Config file not automatically generated if symlink-bindir is only item in config
by Hackage 15 Mar '09

15 Mar '09

#523: Config file not automatically generated if symlink-bindir is only item in config ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: minor | Keywords: config Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I just spent an hour trying to make cabal-install work. After reading the README, I specified the symlink-bindir in the config file. The file did not exist so I created it. Then, when I executed an update, cabal complained that there was no specified repos. I searched and could not find what variable I needed to define in the config file. Then, after skimming the cabal source code, I noticed that the config file is automatically generated if it does not exist. So I deleted it and now all is fine because it was automatically generated. So by following the README instructions by specifying a symlink-bindir variable in a config file I created, I was unable to make cabal work. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/523> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1