March 2011 - cabal-devel

[Hackage] #709: cabal doesn't handle error conditions from getAppUserDataDirectory
by Hackage 05 Jan '12

05 Jan '12

#709: cabal doesn't handle error conditions from getAppUserDataDirectory ----------------------------+----------------------------------------------- Reporter: creswick | 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: Windows | ----------------------------+----------------------------------------------- Distribution.Simple.InstallDirs.defaultInstallDirs fails if getAppUserDataDirectory fails, and it does so with a very uninformative error: {{{ # On Cabal 1.8.0.2: cabal.exe: illegal operation }}} This is a slight regression from the HP 2009 version: {{{ # On Cabal 1.6.0.3: cabal.exe: System.Directory.getAppUserDataDirectory: unsupported operation (unsupported operation) }}} This happens on Windows Vista, in cygwin, when the user doesn't have a windows user directory (eg: c:\users\username ). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/709> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #698: Hayoo! links on Hackage are broken
by Hackage 05 Jan '12

05 Jan '12

#698: Hayoo! links on Hackage are broken --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.3 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- The links to Hayoo! on Hackage point to http://holumbus.fh- wedel.de/hayoo/hayoo.html, which is returning a 404 File Not Found error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/698> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #693: Missing instructions for running Cabal's testsuite
by Hackage 05 Jan '12

05 Jan '12

#693: Missing instructions for running Cabal's testsuite ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It's not quite clear to me how to get `tests/suite.cabal` to build using an in-place build of Cabal. I played around with passing `--package-db ../dist/package.conf.inplace` to `configure` when configuring `tests/suite.cabal` without success. A `tests/README` file would be very useful. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/693> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 10

[Hackage] #778: ConfigFlags { configConfigurationsFlags } field should contain flags which are defined in .cabal file, but aren't specified in command line with -flags=...
by Hackage 05 Jan '12

05 Jan '12

#778: ConfigFlags { configConfigurationsFlags } field should contain flags which are defined in .cabal file, but aren't specified in command line with -flags=... ----------------------------+----------------------------------------------- Reporter: nartamonov | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: | ----------------------------+----------------------------------------------- I have custom Flag declaration in .cabal file: Flag debug Description: Build with debug support Default: True and some conditionals (if flag(debug) ...) which depend on this flag. In custom Setup.hs I use data structure Distribution.Simple.Setup.ConfigFlags and its field configConfigurationsFlags to get value of 'debug' flag. But it seems that field contains flag entry only when I explicitly mention flag during configuration phase in command line with '-fdebug' or '-- flags=debug'. I think it is wrong because even if I don't mention flag in command line he will be initialized to True and conditionals (in *.cabal) which depend on it will be evaluated according to this default value. It would be awesome if I could access flag with its implicitly assigned value via ConfigFlags { configConfigurationsFlags }. My custom Setup.hs machinery heavily depends on values of such flags, and it is inconvenient to explicitly define all of them via command line during configuration phase. Thanks. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/778> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #776: cabal check gives invalid duplicate modules warning
by Hackage 05 Jan '12

05 Jan '12

#776: cabal check gives invalid duplicate modules warning ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Given the Cabal file: {{{ cabal-version: >= 1.2 build-type: Simple name: test version: 4.1 license: GPL category: Test author: Test maintainer: Test synopsis: Test description: Test flag extended-library library if flag(extended-library) exposed-modules: Test else other-modules: Test }}} I get the {{{cabal check}}} output: {{{ The following warnings are likely affect your build negatively: * Duplicate modules in library: Test These warnings may cause trouble when distributing the package: * A 'license-file' is not specified. The following errors will cause portability problems on other environments: * The package is missing a Setup.hs or Setup.lhs script. Hackage would reject this package. }}} The error about Test being duplicate is incorrect - the flag means it will occur at most once. This bug is annoying for Hoogle, which wants to have a library exposing internal details, mainly for documentation purposes, and a normal library as well. Thanks, Neil -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/776> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #793: On OS X, warn about filenames that only differ in case
by Hackage 05 Jan '12

05 Jan '12

#793: On OS X, warn about filenames that only differ in case ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I managed to make Cabal fail to build a project by having {{{ Name: hamt Version: 0.1 License: BSD3 License-file: LICENSE Author: Johan Tibell Maintainer: johan.tibell(a)gmail.com Category: Data Build-type: Simple Cabal-version: >=1.2 Library Exposed-modules: HAMT Other-modules: PopCount Build-depends: base, vector C-sources: popcount.c }}} The result was: {{{ Building hamt-0.1... [1 of 2] Compiling PopCount ( PopCount.hs, dist/build/PopCount.o ) ld: duplicate symbol _popcount in dist/build/popcount.o and dist/build/PopCount.o for inferred architecture i386 }}} `_popcount` is only defined in `popcount.c`. Looking in `dist/` showed that there was only a popcount.o there (from the C file). Renaming `popcount.c` to `popc.c` solved the problem. Cabal ought to warn in this case. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/793> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #788: Optionally exposed modules / APIs should be banned
by Hackage 05 Jan '12

05 Jan '12

#788: Optionally exposed modules / APIs should be banned ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It is a deliberate decision that packages cannot depend on package + flag combinations, only on packages. The point is that flags are not supposed to change the API of a package. This needs to be enforced. Consider a real example (from Chart package: http://hackage.haskell.org/packages/archive/Chart/0.14/Chart.cabal) {{{ if flag(gtk) build-depends: gtk >= 0.9.11 exposed-modules: Graphics.Rendering.Chart.Gtk }}} The criterion package depends on Chart and imports `Graphics.Rendering.Chart.Gtk` meaning that it breaks if you build Chart with the gtk flag turned off. The solution is that Chart should be prevented from conditionally exposing modules. We should add a QA check that looks for exposed modules that are conditional on a flag. It is annoying but somewhat less bad for modules to change between platforms. Should it be a hard failure or just a warning? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/788> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #783: Weird brackets in function names on Haddock page
by Hackage 05 Jan '12

05 Jan '12

#783: Weird brackets in function names on Haddock page --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- Take a look at: http://hackage.haskell.org/packages/archive/harpy/0.4.3.0/doc/html/Harpy- Call.html Here the docs show very weird names such as conv[a9D8]. However, if we look at the source it has #ifndef __HADDOCK__, to make it look fine. But that's not being obeyed on Hackage, for some reason. -- Neil Mitchell -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/783> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #797: Cabal includes test suite dependencies when building the library
by Hackage 05 Jan '12

05 Jan '12

#797: Cabal includes test suite dependencies when building the library ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.10 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- `cabal configure` currently includes the test suite dependencies even without `--enable-tests`. This means that `cabal install <some lib>` will pull in e.g. test-framework, even though that isn't necessary to install the library. For example, given this configuration: {{{ library ... build-depends: base >= 3 && < 4.4, bytestring < 1.0, parsec >= 2.0 && < 3.1.1 if !os(windows) build-depends: unix >= 2 && < 3 test-suite simple ... build-depends: base < 4.4, bytestring < 0.10, HUnit < 1.3, network, test-framework < 0.4, test-framework-hunit < 0.3 test-suite uri ... build-depends: base < 4.4, HUnit < 1.3, network, test-framework < 0.4, test-framework-hunit < 0.3 }}} we get this: {{{ $ cabal configure -v ... Resolving dependencies... selecting network-2.3.0.2 (hackage) selecting HUnit-1.2.2.3 (installed) selecting base-4.3.0.0 (installed) selecting bytestring-0.9.1.8 (installed) selecting ffi-1.0 (installed) selecting ghc-prim-0.2.0.0 (installed) selecting integer-gmp-0.2.0.2 (installed) selecting rts-1.0 (installed) selecting test-framework-0.3.3 (installed) and discarding containers-0.3.0.0 and mtl-1.1.1.0 selecting ansi-terminal-0.5.5 (installed) selecting ansi-wl-pprint-0.6.3 (installed) selecting array-0.3.0.2 (installed) selecting containers-0.4.0.0 (installed) selecting extensible-exceptions-0.1.1.2 (installed) selecting hostname-1.0 (installed) selecting mtl-2.0.1.0 (installed) selecting old-locale-1.0.0.2 (installed) selecting random-1.0.0.3 (installed) selecting regex-base-0.93.2 (installed) selecting regex-posix-0.94.4 (installed) selecting test-framework-hunit-0.2.6 (installed) selecting time-1.2.0.3 (installed) selecting transformers-0.2.2.0 (installed) selecting unix-2.4.1.0 (installed) selecting xml-1.3.7 (installed) selecting parsec-2.1.0.1 (installed) and discarding parsec-3.1.0 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/797> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #679: Hackage website should obscure email addresses
by Hackage 05 Jan '12

05 Jan '12

#679: Hackage website should obscure email addresses --------------------------------+------------------------------------------- Reporter: jbapple | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- Email addresses on hackage are getting captured by spambots. HackageDB can implement solutions that individual maintainers could not (javascript) or reduce the amount of redundant work maintainers have to do. Leaving the field unprotected discourages maintainers from providing email addresses for contact. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/679> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3