March 2009 - cabal-devel

[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] #471: check for ambigious module names
by Hackage 11 Mar '09

11 Mar '09

#471: check for ambigious module names ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Consider an example: {{{ build-depends: base, extensible-exceptions }}} The package `base-4.0.0.0` and `extensible-exceptions-0.1.1.0` both provide the module `Control.Exception`. This means it is impossible to pick both packages as direct dependencies of any single package. We should check for this situation at configure time and/or in cabal- install when planning an installation plan. Actually trying to avoid this situation may be rather tricky and it is not expected to occur often. So a simple check may be sufficient. If it starts to occur often in practice then we could consider trying to get the constraint solver to avoid the situation (perhaps by adding it to the checks for if a package is installable at all, see #420). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/471> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #503: "cabal haddock" should accept --hyperlink-sources (not just --hyperlink-source)
by Hackage 11 Mar '09

11 Mar '09

#503: "cabal haddock" should accept --hyperlink-sources (not just --hyperlink- source) ----------------------------+----------------------------------------------- Reporter: SamB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I don't know how many times I've tried to pass it in the plural... it's getting annoying. What would the best way to get this to work be? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/503> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #514: Detect and warn about documentation with broken links.
by Hackage 11 Mar '09

11 Mar '09

#514: Detect and warn about documentation with broken links. ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: very hard (<1 week) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- There are numerous broken links in the haddock documentation on hackage. Some of these are the result of syntactic mistakes in the markup (eg forgetting to escape quotation marks) and some are just plain stale links. We should have a mechanism to check for such problems and report them to the package author. This would probably involve parsing the html files to look for links. Detecting broken links that are internal to the docs for a single package is not too hard. Broken cross-package links is a bit harder. Detecting stale external links would need to make http GET requests. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/514> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #148: Cabal should be able to produce foreign libs (shared or static)
by Hackage 09 Mar '09

09 Mar '09

#148: Cabal should be able to produce foreign libs (shared or static) ----------------------------+----------------------------------------------- Reporter: eivuokko | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * platform: Windows => * ghcversion: 6.4.2 => * summary: Cabal should be able to produce DLLs in Windows => Cabal should be able to produce foreign libs (shared or static) * milestone: _|_ => Cabal-1.8 Comment: More people are trying to do this kind of thing, see: http://ha4.fajno.net/2009/03/pandoc-can-we-use-it-ouside-of-haskell.html There are also plenty of people in commercial settings doing this on Windows and who could do with more help from Cabal. This ticket mentions Windows and DLLs but we have the same issue with Unix systems and generating shared or static libs for consumption by foreign code. Whatever solution we come up with should be as cross-platform as possible. One question, is the choice of static lib or dynamic lib part of the package description or part of the way we choose to build it? Should we be able to build both from the same description? When you're building it, should you have to specify if you want to make a static lib or shared lib? For Haskell libs we have to say at configure time if we want shared or static. For this case perhaps it's more part of the package description than a configuration option. For Windows DLLs I hope there will be no need to specify `.def` files. We should be able to get the exact export list from the list of FFI ccall/stdcall exports. Note this issue is independent of whether ghc supports shared libs for the RTS and Haskell packages on a particular platform. If it doesn't we just generate massive libs that link in everything. If it does we can make small libs that dynamically link to the RTS and Haskell packages. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/148#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[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] #477: re-configure when the .cabal file changes
by Hackage 09 Mar '09

09 Mar '09

#477: re-configure when the .cabal file changes ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- From http://trevion.blogspot.com/2008/11/cabal-is-fine-piece-of- software.html: {{{ One nice thing about Cabal is that it really helps you appreciate the different parts of the build process. For instance, suppose that I change my cabal metadata file, and then attempt to build my project, for instance by saying runghc Setup.hs build Cabal will helpfully reply: Setup.hs: interpreter.cabal has been changed, please re-configure. Notice how Cabal has helpfully here noticed that there’s work to be done, and not done it. I found that this really helped me appreciate the details of the build, rather than unhelpfully hiding those details behind some veneer of “automation”. }}} We can and should do this. It is annoying. The solution is to save the configure flags that the user gave originally and to use them again to re-configure. This could be a Read/Show style file like we have for the `LocalBuildInfo` or it could be a readable file like the cabal config file. A format and parser derived from the set of command line arguments. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/477> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[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