May 2012 - cabal-devel

[Hackage] #953: Alex-generated Lexer isn't found when building test-suite
by Hackage 15 May '12

15 May '12

#953: Alex-generated Lexer isn't found when building test-suite ----------------------------+----------------------------------------------- Reporter: owst | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.14.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I'd like to use my Alex-generated lexer in my test-suite. I've tried adding other-modules/build-tools to my test-suite section, but upon building the Lexer module isn't found. I've got no problems using the lexer within my normal executable. Should I be able to use my Lexer in the test-suite? I'll attach a fairly minimal example, the Main module and the TestSuite module both use the Lexer, Main will compile, TestSuite won't: $ cabal configure --enable-tests $ cabal build [... blurb] Preprocessing test suite 'tests' for test-suite-with-alex-0.0... tests/TestSuite.hs:7:8: Could not find module `MyLexer' Perhaps you meant Lexer (needs flag -package ghc-7.4.1) Use -v to see a list of the files searched for. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/953> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #951: Incorrect error messages for non-existing dependencies
by Hackage 15 May '12

15 May '12

#951: Incorrect error messages for non-existing dependencies ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: message solver Difficulty: unknown | Ghcversion: 7.4.1 Platform: Linux | ---------------------------------+------------------------------------------ When the build-depends-field contains non-existing packages, cabal-install sometimes does not report that these packages could not be found but complains about other constraints being unsolvable. The attached cabal-file contains a dependency for a non-existing package called "bogus". This is what I get: {{{ $ cabal install --only-dependencies --dry-run Resolving dependencies... cabal: Could not resolve dependencies: next goal: foo (user goal) rejecting: foo-1.0 (global constraint requires ==0.1.0.0) trying: foo-0.1.0.0 trying: heist-0.8.0 (dependency of foo-0.1.0.0) trying: transformers-0.3.0.0 (dependency of heist-0.8.0) next goal: mtl (dependency of heist-0.8.0) rejecting: mtl-2.1.1, 2.1 (conflict: heist => mtl>=2.0 && <2.1) rejecting: mtl-2.0.1.0, 2.0.0.0 (conflict: transformers==0.3.0.0, mtl => transformers==0.2.*) rejecting: mtl-1.1.1.1, 1.1.1.0, 1.1.0.2, 1.1.0.1, 1.1.0.0, 1.0 (conflict: heist => mtl>=2.0 && <2.1) }}} When removing "bogus" from the build-depends, cabal-install is able to come up with a working install plan. Used versions: {{{ $ cabal --version cabal-install version 0.14.0 using version 1.14.0 of the Cabal library }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/951> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #952: cabal-install-0.14.0 dependencies are incorrect
by Hackage 15 May '12

15 May '12

#952: cabal-install-0.14.0 dependencies are incorrect ---------------------------------+------------------------------------------ Reporter: kosmikus | Owner: kosmikus Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14.2 Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Apparently, we depend on transformers >= 0.2.2.0 (indirectly via mtl). Should either adapt the code to work with older versions or fix the dependency. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/952> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #950: no dyn_o generated for C files
by Hackage 11 May '12

11 May '12

#950: no dyn_o generated for C files ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: dynamic objects Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When verifying a bug in GHC-7.5.20120510 I think I discovered a bug in Cabal-1.15.0 that is shipped with the nightly build of GHC. In the llvm-base package the C/C++ modules in the cbits directory are only compiled for the static version and the dynamic objects are not generated. This results in the compiler error: {{{ gcc: dist/build/cbits/extra.dyn_o: file not found gcc: dist/build/cbits/free.dyn_o: file not found gcc: dist/build/cbits/malloc.dyn_o: file not found gcc: dist/build/cbits/support.dyn_o: file not found }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/950> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Heads up - moving the bug tracker to github
by Bryan O'Sullivan 11 May '12

11 May '12

Hi folks - Some time next week, I am planning to import all open Cabal bugs into the github issue tracker. At that point, we should put the Trac issue tracker into read-only mode. Here's a preview of what the imported issues will look like: https://github.com/bos/test1/issues Most issue metadata is preserved, except for being able to attribute issues and their comments directly to users (github's API doesn't allow this).

1 0

[Hackage] #949: cabal should fail if compilation depends on a file not existing in the cabal file
by Hackage 11 May '12

11 May '12

#949: cabal should fail if compilation depends on a file not existing in the cabal file ---------------------------------+------------------------------------------ Reporter: LeventErkok | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Cabal doesn't complain if the build depends on a Haskell module that exists in the filesystem properly, but is not mentioned in the cabal file itself as part of "exposed-modules" or "other-modules". The build succeeds because ghc can find the relevant file just fine. I've got bitten by this several times, especially after pushing a package to hackage, only to get it fail to build on the server because I've failed to put the name of a file in the appropriate section of the cabal file, thus it didn't make it to the .tar.gz bundle that got uploaded to the server. I realize this might be hard to ensure, as it would require a deeper look into the dependencies between modules, but I trust the GHC API should have all the information necessary for cabal to complain appropriately. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/949> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: cabal/pull/2
by Duncan Coutts 07 May '12

07 May '12

On Fri, 2012-05-04 at 21:50 +0200, Tuncer Ayaz wrote: > Hi guys, > > wrt https://github.com/haskell/cabal/pull/2 , I didn't comment there > as there seems to be a consensus on "fork". > > Still, I'd like to question that decision given that "fork" for me > at least carries too much of a "publish an alternative version > with changes" meaning. > > Would fetch or checkout or grab or fetch-scm or something > not be more precise terminology wise? Andres and I discussed this the other day. I think our consensus was to use 'get' and to have that also work for tarballs (like the current 'unpack'). We didn't discuss in detail what a 'get' command would look like, e.g. how to say you want to get the scm version rather than the tarball version. Duncan

1 0

[Hackage] #942: cabal install passes --disable-benchmarks to setups built with Cabal lib versions that don't know that flag
by Hackage 04 May '12

04 May '12

#942: cabal install passes --disable-benchmarks to setups built with Cabal lib versions that don't know that flag ---------------------------------+------------------------------------------ Reporter: kosmikus | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14.2 Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/942> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3