August 2011 - cabal-devel

[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

[Hackage] #676: bash-completion gets confused by alias for rm
by Hackage 05 Jan '12

05 Jan '12

#676: bash-completion gets confused by alias for rm ---------------------------------+------------------------------------------ Reporter: benmachine | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: minor | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: Linux | ---------------------------------+------------------------------------------ I have an alias for rm defined so that it is by default verbose (alias rm='rm -v' in my bashrc). When I do cabal install has<tab> I get something like: [ben@euler ~]$ cabal install hasbash: bad substitution: no closing "`" in `/tmp/cabal_completion.tD2o8O' It turns out that rm is helpfully going: removed `/tmp/cabal_completion.hb1zbc' and then cabal is trying to use this as part of the completion command - choking on the ` because bash thinks it is part of a substitution. So rm should probably explicitly discard its stdout. While I was there I noticed that "cat" is used redundantly. There's nothing really wrong with this so that part of the patch can be cut I suppose, but I thought it was neater to use bash's input redirection explicitly. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/676> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #677: Error: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal"
by Hackage 05 Jan '12

05 Jan '12

#677: Error: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal" ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.10.4 Platform: Linux | ---------------------------------+------------------------------------------ I recently upgraded cabal-install and started getting this error: $ cabal install HDBC Resolving dependencies... cabal: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal" I also get the same error when I try to install one of my own packages that depends on HDBC. I tried changing my HDBC dependency to == 2.2.2 as well as >= 2.2.6, but still get the same error for version 2.2.5. I have cabal-install version 0.6.2 and Cabal version 1.6.0.3. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/677> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #674: Findable extra documentation
by Hackage 05 Jan '12

05 Jan '12

#674: Findable extra documentation ----------------------------+----------------------------------------------- Reporter: jbapple | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a cabal package that should include extra documentation in the distribution. This documentation should not be written in Haddock. 1. There should be a field for this analogous to data-files or extra- source-files. The former is too much: the files do not need to be accessed by any Haskell runtime. The latter is not enough: it does not store the extracted files on the system on which the package is installed. 2. There should be a way for humans to find these files without loading up a GHC runtime or using Unix's "find". I suggest "cabal list" also shows, for installed packages with extra data or documentation files installed, where these files can be found. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/674> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #871: Library with test builds the test executable against the library's cabal_macros.h
by Hackage 07 Dec '11

07 Dec '11

#871: Library with test builds the test executable against the library's cabal_macros.h ----------------------------+----------------------------------------------- Reporter: AntoineLatter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Things like 'VERSION_package' may not only be wrong, but may cause compile errors if the library doesn't include the package in question (but the test does). This is likely to come up in a MIN_VERSION_criterion or MIN_VERSION_HUnit case. This might only be a problem if the test executable is using the new "build against a compiled version of the library" technique - I haven't played around too much. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/871> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #760: exclude all but latest documentation from search results
by Hackage 01 Dec '11

01 Dec '11

#760: exclude all but latest documentation from search results --------------------------------+------------------------------------------- Reporter: warren | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- When searching for haskell documentation on google, quite frequently the top search results are versions of the library documentation from the archives. For instance, when searching for Data.Vector, the top hit is version 0.5, whereas the latest is 0.7. Also, if the user selects the 0.7 version, it isn't obvious from the documentation that this version corresponds to the latest since it also appears in the archive (the url is http://hackage.haskell.org/packages/archive/vector/0.7/doc/html/Data- Vector.html). So I'm wondering if it might not make sense to exclude all but the latest haddock documentation from search results by augmenting the robots.txt file. It might also make sense to provide alternate urls to the latest versions of documents. E.g. Starting from the http://hackage.haskell.org/package/vector page (which is the latest version), and clicking on Data.Vector, one is taken to http://hackage.haskell.org/packages/archive/vector/0.7/doc/html/Data- Vector.html... but it might be better if this were http://hackage.haskell.org/packages/current/vector/doc/html/Data- Vector.html. This would allow for all files under /archive to be excluded. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/760> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1