March 2009 - 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] #453: "cabal fetch" should take output arguments
by Hackage 01 Apr '09

01 Apr '09

#453: "cabal fetch" should take output arguments ---------------------------------+------------------------------------------ Reporter: gregorycollins | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ It would be nice if "cabal fetch" could output the fetched tarball to a location specified on the command line, i.e.: cabal fetch bytestring -o foo.tgz This probably depends on #423. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/453> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #534: cabal haddock should --hyperlink-source by default
by Hackage 31 Mar '09

31 Mar '09

#534: cabal haddock should --hyperlink-source by default ----------------------------------+----------------------------------------- Reporter: adamvo | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- The results from cabal haddock --hyperlink-source are very nice, but quite frequently the haddocks are not built with this (all recent hackage libs iirc). Would there be a problem with generating the source links by default if and only if a HsColour can be found? Or should this issue instead be resolved at the haddock level? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/534> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal-branches/cabal-1.6): Bump version number, 1.6.0.2 -> 1.6.0.3
by Duncan Coutts 27 Mar '09

27 Mar '09

Thu Mar 26 09:38:19 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Bump version number, 1.6.0.2 -> 1.6.0.3 And added a changelog entry M ./Cabal.cabal -2 +2 M ./Makefile -1 +1 M ./README -2 +2 M ./changelog +3 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.6/_darcs/patches/2009032616…

1 0

patch applied (cabal-branches/cabal-1.6): Avoid coping N executables N times (Ticket #525)
by Duncan Coutts 27 Mar '09

27 Mar '09

Tue Mar 17 03:15:45 PDT 2009 Nicolas Pouillard <nicolas.pouillard(a)gmail.com> * Avoid coping N executables N times (Ticket #525) Ignore-this: df195c1daed38005bca165df9a6da880 M ./Distribution/Simple/Install.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.6/_darcs/patches/2009031710…

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 26 Mar '09

26 Mar '09

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn(a)bringert.net | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by guest): * cc: manlio.perillo(a)gmail.com (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:11> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #460: find the http proxy on windows more reliably
by Hackage 24 Mar '09

24 Mar '09

#460: find the http proxy on windows more reliably ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Some network setups (particularly corporate ones) do not use a static proxy set in the windows registry but use [http://msdn.microsoft.com/en- us/library/aa384240%28VS.85%29.aspx "AutoProxy"]. This is a rather complex protocol involving DHCP, dns and requires a !JavaScript interpreter. However the [http://msdn.microsoft.com/en- us/library/aa384273%28VS.85%29.aspx WinHTTP] library comes with Windows as of Win2k SP3, WinXP SP1, Win2k3 and Vista. It's got a bunch of functions for dealing with this AutoProxy stuff, [http://msdn.microsoft.com/en-us/library/aa384122(VS.85).aspx including sample code]. In particular the main function we want is [http://msdn.microsoft.com/en-us/library/aa384097(VS.85).aspx WinHttpGetProxyForUrl] So we could try either statically linking to this, or perhaps doing some dynamic !GetProcAddress funky stuff. Reading more closely, it seems that this only works if the setup is using an !AutoProxy setup. This documentation may be more relevant: * [http://msdn.microsoft.com/en-us/library/aa383660(VS.85).aspx Discovery Without an Auto-Config File] * [http://msdn.microsoft.com/en-us/library/aa384096(VS.85).aspx WinHttpGetIEProxyConfigForCurrentUser] * [http://msdn.microsoft.com/en-us/library/aa384095(VS.85).aspx WinHttpGetDefaultProxyConfiguration] It seems that there are some performance issues with !AutoProxy but any caching has to be fairly careful since the proxy information can change. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/460> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #531: Text.Parsec.Combinators.notFollowedBy too restrictive
by Hackage 23 Mar '09

23 Mar '09

#531: Text.Parsec.Combinators.notFollowedBy too restrictive ----------------------------+----------------------------------------------- Reporter: nzeh | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Say, you want to write something like {{{ aParser :: Parser String aParser = many1 $ noneOf "a" <|> ( char 'a' >> notFollowedBy $ string "rrgh" >> return 'a' ) }}} This fails because, according to the type signature of notFollowedBy, since the parser parses a stream characters, the parser given to notFollowedBy must have return type Char, which it doesn't. The same happens for something a little more meaningful such as {{{ nonFinalA :: Parser () nonFinalA = char 'a' >> notFollowedBy eof }}} because eof has return type (). This is a request to change the type signature of notFollowedBy to accept a parser with arbitrary return type. Rationale: * The return type is ignored anyway. * The return type has only a loose connection with what part of the input stream the parser consumes. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/531> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[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