July 2011 - cabal-devel

[Hackage] #854: BSD2 and ISC license
by Hackage 05 Jan '12

05 Jan '12

#854: BSD2 and ISC license ----------------------------------+----------------------------------------- Reporter: kazu-yamamoto | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Cabal provides BSD3 and BSD4 but not BSD2 and ISC. Please provide them. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/854> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #848: Don't prefix test output with ">>>"
by Hackage 05 Jan '12

05 Jan '12

#848: Don't prefix test output with ">>>" ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: ttuegel Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- The `cabal test` output is a bit too noisy. {{{ $ /tmp/cabal-install/dist/build/cabal/cabal test --show-details=always Running 1 test suites... Test suite tests: RUNNING... >>> Test suite tests: RUNNING... >>> [] bernstein: [Failed] >>> Falsifiable with seed 8771427597089205664, after 1 tests. Reason: Falsifiable >>> text: text/strict: [OK, passed 100 tests] text/lazy: [OK, passed 100 tests] rechunk: [OK, passed 100 tests] text/rechunked: [OK, passed 100 tests] >>> >>> Properties Total >>> Passed 4 4 >>> Failed 1 1 >>> Total 5 5 >>> Test suite tests: FAIL >>> Test suite logged to: dist/test/hashable-1.1.2.0-tests.log Test suite tests: FAIL Test suite logged to: dist/test/hashable-1.1.2.0-tests.log 0 of 1 test suites (0 of 1 test cases) passed. }}} My original request was for the Cabal output (such as "Running 1 test suites...") to be prefixed by ">>>" and the test output to be kept verbatim. This is not quite what happens now as you see above. Here's my new suggestion: since Cabal normally doesn't prefix command output, we should not do so in the test output either. Just output stdio verbatim from the test and don't prefix anything with ">>>". -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/848> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #860: Package seems to depend on itself
by Hackage 05 Jan '12

05 Jan '12

#860: Package seems to depend on itself --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- In the list of dependencies of the package language-c-quote[0], the name of the package itself is mentioned. [0] http://hackage.haskell.org/package/language-c-quote -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/860> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #863: Can't pass extra arguments to c2hs
by Hackage 05 Jan '12

05 Jan '12

#863: Can't pass extra arguments to c2hs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: c2hs, arguments Difficulty: unknown | Ghcversion: Platform: Mac OS | ---------------------------------+------------------------------------------ With cabal-install 0.10.2, I am no longer able to pass extra arguments to c2hs. When invoked as: {{{ cabal install -O --c2hs-option=--cppopts=-U__BLOCKS__ --c2hs-options="-- dump=trace" -v }}} c2hs is then called as {{{ /Users/localuser/.cabal/bin/c2hs --cpp=/usr/bin/gcc --cppopts=-E --cppopts=-D__GLASGOW_HASKELL__=700 --cppopts=-Ddarwin_BUILD_OS --cppopts=-Ddarwin_HOST_OS --cppopts=-Dx86_64_BUILD_ARCH --cppopts=-Dx86_64_HOST_ARCH --cppopts=-Icbits --cppopts=-DUSE_SSE2 --include=dist/build --cppopts=-I/Users/localuser/.cabal/lib/vector-0.7.0.1/ghc-7.0.4/include --cppopts=-I/Users/localuser/.cabal/lib/primitive-0.3.1/ghc-7.0.4/include --cppopts=-I/opt/local/include/ --cppopts=-I/usr/local/lib/ghc-7.0.4/base-4.3.1.0/include --cppopts=-I/usr/local/lib/ghc-7.0.4/include --cppopts=-I/usr/local/lib/ghc-7.0.4/include --output-dir=dist/build --output=Sound/Barnet/BandedLib.hs src/Sound/Barnet/BandedLib.chs --cppopts=-U__BLOCKS__ --dump=trace }}} The extra arguments are appended to the end of the call, however c2hs (at least c2hs-0.16.3) requires that the .chs binding file come after all options. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/863> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #724: Add getDataDirectory function to Paths_pkgname
by Hackage 05 Jan '12

05 Jan '12

#724: Add getDataDirectory function to Paths_pkgname ----------------------------+----------------------------------------------- Reporter: tommd | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Some libraries and programs have a large number of files. Instead of having explicit knowledge of each file (and instead of using a mutation on the result of getDataFilename) there should be a "getDataDirectory" or a "getDataDirectoryContents": getDataDirectoryContents = getDataDirectory >>= getDirectoryContents -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/724> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #739: cabal install regression with GHC HEAD - ghc-paths
by Hackage 05 Jan '12

05 Jan '12

#739: cabal install regression with GHC HEAD - ghc-paths ----------------------------+----------------------------------------------- Reporter: AntoineLatter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- with the Cabal library installed with GHC 6.13.20100911 I can no longer install the package ghc-paths-0.1.0.6 In 'ghci Setup.hs' I get the error: Setup.hs:41:25: Ambiguous occurrence `None' It could refer to either `Distribution.Simple.Setup.None', imported from Distribution.Simple.Setup at Setup.hs:2:1-32 or `Pkg.None', imported from Distribution.Simple.PackageIndex at Setup.hs:7:1-46 It looks like the 'None' constructor didn't exist in Distribution.Simple.Setup in Cabal 1.8.x. While we can't guarantee that an added constructor doesn't conflict with data declarations used in every Setup.hs, it seems in poor form to export the same constructor in two types in the same library. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/739> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[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] #803: cabal test after cabal configure --enable-tests without cabal build creates obscure output
by Hackage 05 Jan '12

05 Jan '12

#803: cabal test after cabal configure --enable-tests without cabal build creates obscure output ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It wasn't obvious to me that cabal build would be required before cabal test. Can cabal test automatically run cabal build? Otherwise a message should be shown telling the user to run cabal build. Here is an example output {{{ >>> Test suite runtests: RUNNING... >>> Test suite runtests: FAIL >>> Test suite logged to: dist/test/persistent-0.4.0.1-runtests.log >>> Test suite runtests: RUNNING... >>> Test suite runtests: FAIL >>> Test suite logged to: dist/test/persistent-0.4.0.1-runtests.log Test suite runtests: FAIL Test suite logged to: dist/test/persistent-0.4.0.1-runtests.log 0 of 1 test suites (0 of 1 test cases) passed. }}} The log is exactly the same as the output -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/803> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4