September 2010 - cabal-devel

[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] #735: cabal haddock --executables --hyperlink-source does not call HsColour
by Hackage 05 Jan '12

05 Jan '12

#735: cabal haddock --executables --hyperlink-source does not call HsColour ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I am using "cabal haddock --executables --hyperlink-source" and this generates the API docs for all modules, and all have source links, but the actual html-ized source is only generated for the main module, and missing for all others. Cf. discussion at http://article.gmane.org/gmane.comp.lang.haskell.cafe/78987 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/735> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #742: build-depends in Executable sections are unexpectedly global
by Hackage 05 Jan '12

05 Jan '12

#742: build-depends in Executable sections are unexpectedly global ----------------------------+----------------------------------------------- Reporter: benmachine | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When I have two executable sections, it seems that the build-depends of one are used in the other. For example, the following: state.cabal {{{ Cabal-Version: >= 1.2 Name: state Version: 0.1 Build-type: Simple Executable state-tf Main-is: Main.hs Build-depends: base, transformers, monads-tf Executable state-mtl Main-is: Main.hs Build-depends: base, mtl }}} Main.hs {{{ module Main where import Control.Monad.State main = print $ runState (put ()) undefined }}} fails to compile: {{{ Preprocessing executables for state-0.1... Building state-0.1... Main.hs:3:7: Ambiguous module name `Control.Monad.State': it was found in multiple packages: monads-tf-0.1.0.0 mtl-1.1.1.0 }}} If this is intended (which I doubt) it's at least confusing. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/742> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #734: support multiple .cabal files
by Hackage 05 Jan '12

05 Jan '12

#734: support multiple .cabal files ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ if there are several *.cabal files in the working directory, then "cabal configure" complains, and does nothing. That's OK, but it should then have an option for picking one of these files (cf. "make -f FILE"). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/734> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #736: Win32 missing
by Hackage 05 Jan '12

05 Jan '12

#736: Win32 missing --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- I have uploaded a package to Hackage but it had a build failure: cabal-setup: At least the following dependencies are missing: Win32 -any If Win32 library is missing, all packages with Win32 as dependency will have a build failure. I guess the Win32 build failure is the source of the problem. Although, its documentation is well built (manually, I guess). In my computer, the package installs correctly, because Win32 comes with the Haskell Platform. But, in my opinion, online documentation should work fine. Thanks in advance. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/736> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #741: cabal-install: wrong use of mktemp in bash completion script
by Hackage 05 Jan '12

05 Jan '12

#741: cabal-install: wrong use of mktemp in bash completion script ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ The following bug was reported by Jan Braun against the Debian bugtracker at http://bugs.debian.org/597769 Hi, the bash completion script 1) does not check the return value of mktemp and 2) fails in the presence of "set -o noclobber" attached is a patch to fix both. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/741> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #730: patch: add a separator before the pid suffix to the tmpdir template
by Hackage 05 Jan '12

05 Jan '12

#730: patch: add a separator before the pid suffix to the tmpdir template ----------------------------------+----------------------------------------- Reporter: juhp | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Currently Cabal appends the pid directly to the package name-version which makes it hard to read the actual package version number. The attached patch inserts a '-' between name-version and pid. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/730> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[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