July 2010 - cabal-devel

[Hackage] #716: Inconsistent behavior between custom and simple build types
by Hackage 05 Mar '12

05 Mar '12

#716: Inconsistent behavior between custom and simple build types ---------------------------------+------------------------------------------ Reporter: j3h | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ If a Custom build-type is used, Setup.hs may be built with a different version of Cabal than the one that cabal-install was built with. This can cause hard-to-find (seemingly random) build failures. Perhaps cabal-install should warn when it runs Setup.hs with a different version of Cabal than the one that it was built with. Alternatively, it could fail if the version of Cabal that cabal-install was built with is not available when compiling the Setup script. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/716> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #719: tool support for checking if a package works with a range of versions
by Hackage 05 Mar '12

05 Mar '12

#719: tool support for checking if a package works with a range of versions ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ [http://www.haskell.org/pipermail/libraries/2010-July/013970.html Doaitse reports] that he would like: {{{ since I do not have a wide variety of Haskell installations and package versions on my machine, it would be very nice if the hackage server could test a package against the extremes of the indicated dependency ranges before installing. This would have prevented the mistake I made (and which undoubtedly others will make too) }}} Others responded that they would also like to do the same thing locally, even though the range of versions they have locally may be limited. So one simple approach would be a flag to indicate a preference that the earliest version of a package (or all packages?) be used rather than the latest version. This might be integrated into a "cabal disttest" feature that makes a tarball and builds from the tarball. The same approach could be taken for hackage build bots. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/719> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #667: Improve tools to manage ad-hoc package releases
by Hackage 05 Jan '12

05 Jan '12

#667: Improve tools to manage ad-hoc package releases ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Hackage is suited for major software releases by package maintainers. It is not suited to distributing betas, daily snapshots or random forks, or patches of existing releases. For example a user may have some patch or bugfix for a package that they need. It takes time for maintainers to review and integrate these. Sometimes maintainers have little time, or they disagree with a patch approach or quality. It is right that maintainers have control over what is released on hackage. However there is a need for decentralised, ad-hoc and short term releases. We do not want to encourage the pollution of the package namespace with lots of short-term forks. One solution is to let users post package forks on their own webspace. We would want to extend cabal so that people can run: {{{ cabal install http://code.haskell.org/~user/foo/foo-fork-to-fix- blah-1.0.1.tar.gz }}} This makes it very decentralised. We may want to add some feature to hackage package pages to link to third-party forks. In addition to hosting and installing single packages it would be useful to be able to publish package collections. Of course this is exactly what a hackage archive is. We should provide easy tools to make and manage hackage archives that can be hosted on dumb http file servers. Going one step further, the hackage index format should be extended to make it more RESTful by including links to tarballs rather than just assuming that tarballs are found relative to the index file using some fixed layout. This would allow people to publish indexes that span multiple servers. This gets close to the concept of a package "search path" promoted by the searchpath project (http://searchpath.org/) Additonally, an index should allow us to point to source control repos rather than just to release tarballs. This kind of index would be useful for nighly builds. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/667> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #671: better error message for broken build tools
by Hackage 05 Jan '12

05 Jan '12

#671: better error message for broken build tools ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Consider: {{{ Configuring haskell-src-exts-1.9.0... setup: happy version >=1.17 is required but the version of /usr/local/bin/happy could not be determined. }}} The actual problem is: {{{ /usr/local/bin/happy: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory }}} We could produce a better error message in this situation. If we get a non-0 exit code when we check the `--version` then we can probably safely report that the program is probably broken. Of course if we get some result text back and we cannot extract and parse the version number then that's different. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/671> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #663: Setup.hs doesn't look into ~/.cabal/bin for build tools.
by Hackage 05 Jan '12

05 Jan '12

#663: Setup.hs doesn't look into ~/.cabal/bin for build tools. ----------------------------------+----------------------------------------- Reporter: Axel Simon | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Cabal currently only checks the current PATH for buildtools. If the user installs and new pre-processor with the default --user installation, these tools wind up in ~/.cabal/bin. However, cabal doesn't find these unless ~/.cabal/bin has been added to the PATH. This is irritating since it is then not possible to make a library depend on a cabal package that contains it's build tools: Even if cabal-install installs the build tools first, building the library still fails since the tools cannot be found. The solution is very simple: Add ~/.cabal/bin to the search path when looking for build tools! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/663> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #701: Help packages to avoid linker symbol clashes
by Hackage 05 Jan '12

05 Jan '12

#701: Help packages to avoid linker symbol clashes ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently it is all too easy to end up with silently clashing linker symbols. The prime example is C code linked into a Haskell package. Multiple versions of the same package will define the same linker symbols. The system linker is happy to just pick the first occurrence of a symbol (though the ghci linker is stricter). This can cause havoc if the behaviour of the C code changes from one version of the package to another (see for example the problem with mmap and darcs, ticket #700). There are a number of things we could do to improve the situation. * We could make it easier to make versioned C symbols in the C code used in a Haskell package by providing cpp macros. * We could explicitly check for unversioned C symbols in Haskell libs * We could try linking Haskell libs in such a way that the C symbols are not visible and thus cannot clash, but it would also mean they are not exported for other libs to use. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/701> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #715: glib should require gtk2hs-buildtools
by Hackage 05 Jan '12

05 Jan '12

#715: glib should require gtk2hs-buildtools ----------------------------+----------------------------------------------- Reporter: JadeNB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.2 Platform: Mac OS | ----------------------------+----------------------------------------------- I just installed GHC 6.12.3 (it's not an option on the drop-down GHC version menu, which is why I said 6.12.2 there) and Haskell Platform on Mac OS X Leopard (10.5.8) from source, and tried to install glib. I got: {{{ $ cabal install glib Resolving dependencies... /var/folders/9I/9Ic7OfDBGVmrCPM+NiQOAWp80Kc/-Tmp-/glib-0.11.092062/glib-0.11.0/Gtk2HsSetup.hs:25:0: warning: #warning Setup.hs is guessing the version of Cabal. If compilation of Setup.hs fails use -DCABAL_VERSION_MINOR=x for Cabal version 1.x.0 when building (prefixed by --ghc-option= when using the 'cabal' command) [1 of 2] Compiling Gtk2HsSetup ( /var/folders/9I/9Ic7OfDBGVmrCPM+NiQOAWp80Kc/-Tmp-/glib-0.11.092062/glib-0.11.0/Gtk2HsSetup.hs, /var/folders/9I/9Ic7OfDBGVmrCPM+NiQOAWp80Kc/-Tmp-/glib-0.11.092062/glib-0.11.0/dist/setup/Gtk2HsSetup.o ) [2 of 2] Compiling Main ( /var/folders/9I/9Ic7OfDBGVmrCPM+NiQOAWp80Kc/-Tmp-/glib-0.11.092062/glib-0.11.0/Setup.hs, /var/folders/9I/9Ic7OfDBGVmrCPM+NiQOAWp80Kc/-Tmp-/glib-0.11.092062/glib-0.11.0/dist/setup/Main.o ) Linking /var/folders/9I/9Ic7OfDBGVmrCPM+NiQOAWp80Kc/-Tmp-/glib-0.11.092062/glib-0.11.0/dist/setup/setup ... Configuring glib-0.11.0... setup: gtk2hsC2hs is required but it could not be found. cabal: Error: some packages failed to install: glib-0.11.0 failed during the configure step. The exception was: ExitFailure 1 }}} Running {{{ $ cabal install gtk2hs-buildtools ... $ cabal install glib ... }}} works fine, so I think that it is just a missing dependency. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/715> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #702: cabal should reject relative paths for extra-lib/include-dirs
by Hackage 05 Jan '12

05 Jan '12

#702: cabal should reject relative paths for extra-lib/include-dirs ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It makes no sense and causes problems later. See ghc ticket http://hackage.haskell.org/trac/ghc/ticket/4134 This applies to the paths in the .cabal file. For ones specified on the command line perhaps just making them absolute would be ok. Ones specified in the global config must be absolute. Ones in local config could possibly be relative. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/702> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #713: Distribution/Client/Dependency/TopDown.hs:171:37-73: Non-exhaustive patterns in lambda
by Hackage 05 Jan '12

05 Jan '12

#713: Distribution/Client/Dependency/TopDown.hs:171:37-73: Non-exhaustive patterns in lambda ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.12.1 Platform: | ----------------------------------+----------------------------------------- $> cabal install base Resolving dependencies... cabal: Distribution/Client/Dependency/TopDown.hs:171:37-73: Non-exhaustive patterns in lambda $> ghc-pkg list base /Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.1/package.conf.d base-3.0.3.2 base-4.2.0.0 /Users/wren/.ghc/i386-darwin-6.12.1/package.conf.d $> ghc-pkg list Cabal /Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.1/package.conf.d Cabal-1.8.0.2 /Users/wren/.ghc/i386-darwin-6.12.1/package.conf.d Cabal-1.8.0.6 $> cabal info base * base (library) Synopsis: Basic libraries Latest version available: 4.2.0.2 Latest version installed: 4.2.0.0 Homepage: [ Not specified ] Bug reports: http://hackage.haskell.org/trac/ghc/newticket?component=libraries/base Description: This package contains the Prelude and its support libraries, and a large collection of useful libraries ranging from data structures to parsing combinators and debugging utilities. License: BSD3 Maintainer: libraries(a)haskell.org Source repo: http://darcs.haskell.org/packages/base/ Flags: integer-simple Dependencies: rts -any, ghc-prim -any, integer-simple -any, integer-gmp -any Documentation: /Library/Frameworks/GHC.framework/Versions/612/usr/share/doc/ghc/html/libraries/base-4.2.0.0 Cached: No Modules: [...] -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/713> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #711: cabal install cabal-install fails for OSX dmg
by Hackage 05 Jan '12

05 Jan '12

#711: cabal install cabal-install fails for OSX dmg ----------------------------+----------------------------------------------- Reporter: hartrock | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: Mac OS | ----------------------------+----------------------------------------------- After installing http://hackage.haskell.org/platform/2010.1.0.0/haskell- platform-2010.1.0.1-i386.dmg the following occurs: see attached file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/711> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2