January 2011 - cabal-devel

[Hackage] #697: Add "cabal build-dep" command
by Hackage 05 Jan '12

05 Jan '12

#697: Add "cabal build-dep" command ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: major | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The [http://hackage.haskell.org/trac/ghc/wiki/HackageTesting hackage testing tool] needs a "cabal build-dep" command to work. I had an inadequate patch that was good enough for my experiments (http://osdir.com/ml/cabal-devel@haskell.org/2010-01/msg00029.html) but lack the familiarity with the cabal-install design necessary to implement it properly. Sadly, the patch no longer applies to cabal-install HEAD, and regardless, it would make things a lot easier if it Just Worked out of the box. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/697> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[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