September 2010 - cabal-devel

[Hackage] #740: Allow specifying private C libs to avoid overlinking (but allow static linking)
by Hackage 20 Sep '10

20 Sep '10

#740: Allow specifying private C libs to avoid overlinking (but allow static linking) ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- See http://wiki.mandriva.com/en/Overlinking for a discussion of under and overlinking. In different circumstances, we want both to be able to link to C libs statically and dynamically. For the dynamic case we only want to specify direct C lib dependencies or we end up overlinking. For the static case we must specify all direct and indirect C libs or we will miss libs and get missing symbols. A sensible solution is to follow [http://people.freedesktop.org/~dbn/pkg- config-guide.html pkg-config] and specify "private" C libs separately from normal public ones. This would require extensions both to .cabal files and package registration files. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/740> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Bump dependencies
by Ian Lynagh 18 Sep '10

18 Sep '10

Fri Sep 17 11:38:49 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Bump dependencies M ./Cabal.cabal -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

darcs patch: Ticket #739 (Don't export two constructors named None).
by Antoine Latter 14 Sep '10

14 Sep '10

I also removed one of the constructors while I was in there. Let me know if you prefer a different approach. 1 patch for repository http://darcs.haskell.org/cabal: Tue Sep 14 18:48:16 CDT 2010 Antoine Latter <aslatter(a)gmail.com> * Ticket #739 (Don't export two constructors named None).

1 0

[Hackage] #738: Recompiling the same library version can change its ABI, causing breakage (even of Cabal)
by Hackage 12 Sep '10

12 Sep '10

#738: Recompiling the same library version can change its ABI, causing breakage (even of Cabal) ----------------------------+----------------------------------------------- Reporter: Blaisorblade | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: major | Keywords: Difficulty: unknown | Ghcversion: 6.10.4 Platform: | ----------------------------+----------------------------------------------- On my system, cabal recompiled a package on which Cabal itself depended, breaking the linking of Setup.hs when trying to update new packages. My problem was partially due to an upgrade of a "core package" (on which cabal depends): install of core packages should be refused, for the same reason that "cabal upgrade" is disabled. But that's a side issue, probably known. Recompiling a non-core package could break silently another non-core package, in the same way. The root problem, IMHO, stems from handling of dependencies. Compiler-generated identifiers are exported, due to cross- module linking, and they depend from used modules and options about compilation (especially optimization). It thus seems that the ABI of a module is a (pure) function of the versions of all its (transitive) dependencies, and their compilation options - in particular, the optimization options and the used compiler version. Surely, the ABI does not depend just on the package version. More formally, my conjecture is: - let us represent "package a depends on b" as "a =>> b", where a, b are package names tagged with a version - let =>>* be the transitive-reflexive closure of =>> we need to compute: DEPS(p) = {q | p =>>* q } TAGGED_DEPS(p) = { (q, compilation_opts(q)) | q \in DEPS(p) } where compilation_opts(q) are the compilation options used to compile package q. Then, the ABI of package p is a pure function of TAGGED_DEPS(p), not just of p. My experience proves at least that the ABI does not depend just on p. Possibly, a package ABI depends on the build ID, if internally generated identifiers are random, but it does not look like that on my system (they are sequentially generated). Finally, there should be a way to automatically recompile dependent packages, as in Gentoo's revdep-rebuild. In my case, I wasn't prevented by ghc-pkg from removing a package on which other packages depended, while it does do some dependency tracking. Further info is being discussed on Haskell-cafe in this thread: http://groups.google.com/group/haskell- cafe/browse_thread/thread/838f2c098941bac9 Software versions: cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library (installed through Hackage, not available in this bug report form under "version"). GHC 6.10.4 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/738> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #234: track installed files to allow uninstall
by Hackage 11 Sep '10

11 Sep '10

#234: track installed files to allow uninstall ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: cabal-install tool | Version: 1.2.3.0 Severity: major | Keywords: Difficulty: hard (< 1 day) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Changes (by Blaisorblade): * cc: p.giarrusso@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/234#comment:12> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #737: Cabal check warns about ill-specified dependencies
by Hackage 09 Sep '10

09 Sep '10

#737: Cabal check warns about ill-specified dependencies ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Packages that get listed here: http://hackage.haskell.org/packages/archive/preferred-versions Get special treatment from cabal-install. It would help package authors if 'cabal check' could warn about version ranges, especially for packages listed in the preferred-version file. For example, if the .cabal file just mentions package FOO and preferred- versions asks for FOO < X, then the author might not be aware that some people might expect to use FOO >= X. It would be nice to let the author know that they need to say, FOO == Y.* or FOO > A && FOO < B. This is particularly important for base, where lacking an upper bound leads to bad build behavior. This should probably be implemented in the Cabal library. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/737> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #656: Cabal-1.8-style dependencies stop Haddock from working
by Hackage 07 Sep '10

07 Sep '10

#656: Cabal-1.8-style dependencies stop Haddock from working ------------------------------+--------------------------------------------- Reporter: Ivan Miljenovic | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ------------------------------+--------------------------------------------- Changes (by simonmic): * cc: simon@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/656#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): add a separator before the pid suffix to the tmpdir template
by Duncan Coutts 06 Sep '10

06 Sep '10

Sun Aug 22 18:27:55 PDT 2010 Jens Petersen <petersen(a)haskell.org> * add a separator before the pid suffix to the tmpdir template Currently Cabal just appends the pid to the package name-version which makes it hard to see the actual package version number. This patch just inserts a '-' between name-version and pid. M ./Distribution/Compat/TempFile.hs -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Mention self-referential dependency feature in Cabal >= 1.8.0.4.
by Duncan Coutts 06 Sep '10

06 Sep '10

Thu Jun 10 19:27:49 PDT 2010 ezyang(a)mit.edu * Mention self-referential dependency feature in Cabal >= 1.8.0.4. M ./doc/Cabal.markdown -1 +4 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Pass additional parameters in generated shell scripts
by Duncan Coutts 06 Sep '10

06 Sep '10

Sun May 16 09:12:30 PDT 2010 Matthias Kilian <kili(a)outback.escape.de> * Pass additional parameters in generated shell scripts While here, simplify the argument list construction in invocationAsShellScript a little bit. M ./Distribution/Simple/Program/Script.hs -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0