- cabal-devel - Haskell.org

[Hackage] #626: Package build error due to unicode
by Hackage 18 Mar '10

18 Mar '10

#626: Package build error due to unicode --------------------------------+------------------------------------------- Reporter: basvandijk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- The following packages don't build on hackage due to the same error: * http://hackage.haskell.org/package/regions-0.3 * http://hackage.haskell.org/package/ftdi-0.1 The [http://hackage.haskell.org/packages/archive/regions/0.3/logs/failure/ghc-6.… log] contains the following error: {{{haddock: internal Haddock or GHC error: dist/doc/html/regions/regions.txt: commitAndReleaseBuffer: invalid argument (Invalid or incomplete multibyte or wide character)}}} I think the .txt file is generated because of the haddock {{{--hoogle}}} flag. '''Note that these package make heavy use of Unicode syntax and symbols.''' Note that {{{cabal haddock}}} works perferctly on my local system (tested with ghc-6.10.4 + haddock-2.5 + cabal-install-0.6.2 and ghc-6.12.1 + haddock-2.6.0 + cabal-install-0.8.0) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/626> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): Document the "manual" attribute of flags
by Ian Lynagh 17 Mar '10

17 Mar '10

Wed Mar 17 13:37:44 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Document the "manual" attribute of flags M ./doc/Cabal.xml +15

1 0

patch applied (cabal): Tweak doc Makefile
by Ian Lynagh 17 Mar '10

17 Mar '10

Wed Mar 17 13:24:18 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Tweak doc Makefile M ./doc/Makefile -1 +5

1 0

[Hackage] #644: Equivalent of autoconf's --without-bla
by Hackage 17 Mar '10

17 Mar '10

#644: Equivalent of autoconf's --without-bla ----------------------------+----------------------------------------------- Reporter: Eelis | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a package comprising multiple executables. One of these is optional and has additional dependencies. Because the majority of my users will want to use this executable, I want to build it by default. However, users who do /not/ need it should have the option of turning off building of the executable (removing the need for the additional dependencies). My naive approach to accomplish this with Cabal is as follows: I first declare a flag corresponding to the executable, with a default value of true. I then use: executable theexecutable if flag(theflag) ... else buildable: False This almost does what I need. The problem is that when the user does /not/ have the dependencies needed for the executable, Cabal actually silently sets the flag to false and doesn't build the executable. I realize this is part of some clever backtracking/satisfiability scheme which is undoubtedly useful in certain cases, but in this case it just gets in the way and confuses the hell out of my users who end up missing the executable (because they lacked the additional dependencies). What I really want is for Cabal to keep its paws off this particular flag, so that if the user lacks the dependencies, they get an error (unless they manually unset the flag to inhibit building of the executable). In other words, all I really want is an equivalent of autoconf's --without-bla option. Surely this can't be too hard for Cabal? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/644> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #576: Show reverse dependencies
by Hackage 16 Mar '10

16 Mar '10

#576: Show reverse dependencies --------------------------------+------------------------------------------- Reporter: Lenny222 | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: dependencies Difficulty: easy (<4 hours) | Ghcversion: Platform: | --------------------------------+------------------------------------------- Suggestion: for every package show which other packages (if any) depend on it. Why? Many packages on http://hackage.haskell.org/ do not provide exmaples or documentation. It could be very helpful to look at packages which use the package on is interested in. This can be made easier if every package on http://hackage.haskell.org/ displays which other packages depend on it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/576> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

Proposed ghc-pkg and cabal feature
by Dan Knapp 16 Mar '10

16 Mar '10

I came up with an idea for a small feature that I believe would make a useful addition to ghc-pkg and Cabal. I'm willing to implement it myself, but I have had some previous experiences with other projects where I did some work and then the maintainers said "sorry, not interested", so I want to gauge interest before I start. I've already posted to glasgow-haskell-users, where Simon Marlow was kind enough to respond; he suggested that before starting work I should also get people's opinions here. The feature itself is this: Arbitrary key-value pairs in Cabal package files and the installed-package database. The use-case is for an application supporting plugins to discover installed plugins compatible with it, interrogating these fields through the GHC API. For example, my content-management system FruitTart could enumerate the list of installed packages looking for packages which export a field "fruit-tart-plugin-interface-version" with a numeric value matching the interface version it's expecting. Once again, I'm not asking anyone to do this work for me - I'm eager to get my hands dirty and do it myself. I just want to find out what the process would be to get it accepted, once it works. Thanks in advance, -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

1 0

[Hackage] #215: Overhaul support for package's tests
by Hackage 15 Mar '10

15 Mar '10

#215: Overhaul support for package's tests ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- The current support for running package's testsuites is almost uniformly unused and packages instead implement ad-hoc solutions which makes it hard for users to run the testsuites and impossible to automate on hackage. The current support is so trivial anyone who takes this task on can ignore it and start with a clean slate. A [http://www.haskell.org/pipermail/cabal-devel/2008-January/001661.html thread on the issue]. Here are some ideas for possible requirements: * Support tests even in the `Simple` build system. Do not require using the `build-type: Custom` just to be able to use tests. * Define a standard interface for returning test results from a testsuite to Cabal so they can be included into a build report and could be published on the hackage website or some other custom in-house test server. * Support for above interface in `QuickCheck` and `HUnit`. * Support for HPC when running testsuite programs, and gathering coverage results, again for reporting purposes. * We want to be able to run tests on a library that is not installed yet. This will rely on support in Cabal for registering a package inplace in a local package db, and building test code against that. * What about performance tests? What format should that use for reporting? The emphasis is on automation. A lot of interesting information becomes available with enough automation. For example we could compare on hackage which packages have more comprehensive testsuites (measured by HPC coverage). Or we could track performance over time. Once the data is available there is a lot we could do with it. It's not just for a public hackage server, developers could use this privately too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/215> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

Google summer of code in Cabal?
by Diego Echeverri 15 Mar '10

15 Mar '10

Hi guys! I was wondering about the possibility to work on Cabal for the summer of code. I've been helping one of my teachers to provide (improve) a "plugin" for the uuagc (I haven't spent too much time on it, but here's the fork I'm working on http://github.com/diegoeche/uuagc) I have found how flexible the cabal libraries are but also some things haven't been straightforward to do (I've been using Cabal 1.6.0.3). Basically there's seems to be an assumption of a one-to-one relation of modules and the sources of the files which is not followed by the uuagc pre-processor. I can use List.ag and inside of it use an include declaration to List-Data.ag. If I modify List-Data.ag cabal won't precompile it again because it will only check dates against List.ag (cabal doesn't know that the file that generates List.hs depends not only in List.ag). I had to override the build hook, duplicate the check (this time getting all the dependencies) and delete the generated file to trick cabal to precompile again... and well... that's seems quite a nasty hack to me. This assumption also affect the possibility to make the output of the pre-processor not necessarily an .hs file (and not necessarily carrying the same name). Checking the code for the pre-processors (Distribution.Simple.PreProcess) I noticed it would be good to have the possibility to chain pre-processors. I believe both issues are pretty much connected. I also found the following proposal here: http://hackage.haskell.org/trac/summer-of-code/ticket/1581 which sound also interesting to me. (and there's already a mentor available!) Do you think this could be a good project for the summer of code? Maybe any other ideas I should explore? Did I write to the right list? (please excuse me if I didn't) Thanks! Diego Echeverri

2 1

[Hackage] #643: Cabal should warn & detect when no modules are imported/used from a declared dependency
by Hackage 14 Mar '10

14 Mar '10

#643: Cabal should warn & detect when no modules are imported/used from a declared dependency -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: Platform: | -----------------------------+---------------------------------------------- For context, see: http://www.haskell.org/pipermail/libraries/2010-March/013115.html http://www.haskell.org/pipermail/libraries/2010-March/013155.html http://www.haskell.org/pipermail/libraries/2010-March/013157.html Not a few Haskell packages had declared in their .cabal files that they used the 'haskell98' package; but they never imported anything from haskell98 (such as the Monad or List modules), as proven by simply removing the dependency and noting that it continued to compile. Apparently the authors were mistaken about the use, had updated the old module imports, or believed haskell98 did something it didn't. The authors never knew, because neither GHC, Cabal, nor cabal-install would ever warn about the superfluous dependency. Given that dependencies can cause failures quite easily via bit-rot or the diamond dependency problem, otiose deps are quite bad. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/643> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

cabal-install: Legacy uris and upload --check
by Antoine Latter 13 Mar '10

13 Mar '10

cabal-dev, I found it difficult to test out a local install of hackage due to the way that cabal-install redirects to 'legacy' URIs, and the fact that upload --check points to a hard-coded path. So attached is a patch which does two things: - Previously, only hackage.haskell.org could count as a legacy repo path, now localhost can also count. It's still a bit arbitrary, tough. - When not using a legacy repo URI, upload --check posts to <repo>/check, which is what the happstack-based hackage-server expects. This is similar to what we do for the upload command already. If folks would like the second half without the first, I can put together a new patch. Side effects of this patch: + Anyone running with a third-party repo in their cabal config file will get unexpected behavior with 'upload --check'. Previously this would have always hit hackage.haskell.org. + Anyone running with a repo URI of the format 'localhost/packages/archive' will now be posting 'cabal upload' commands to localhost/cgi-bin/protected/upload instead of localhost/packages/archive/upload. Take care, Antoine

1 0