ANN: Cabal 1.22 and cabal-install 1.22
On behalf of the cabal developers, I'm happy to announce the Cabal 1.22 release! To install: cabal update && cabal install Cabal-1.22.0.0 cabal-install-1.22.0.0 Please report bugs at https://github.com/haskell/cabal/issues. Pre-built binaries should be available with a week or so. Non-exhaustive list of changes: * Support GHC 7.10. * Experimental DWARF debug info output on GHC 7.10 (--enable-debug-info). * Preliminary support for relocatable packages. * Cabal can now be used inside a cabal exec environment. * Fix solver bug where the user's manual flag choice was ignored. * Add GHCJS support. * Improved command line documentation. * Build C sources with -fPIC when GHC is using dynamic libraries. * Preliminary support for package keys (a step on the way to NixOS-like packages). * Add a 'user-config' command to help users manage ~/.cabal/config. * HPC support improved. Here are all the contributors to this release, ordered by number of commits: 181 Mikhail Glushenkov 48 Johan Tibell 35 Edward Z. Yang 34 Christiaan Baaij 32 Thomas Tuegel 24 Ben Armston 19 Ian D. Bollinger 17 Lennart Spitzner 12 Luite Stegeman 11 Herbert Valerio Riedel 10 Duncan Coutts 9 Erik de Castro Lopo 8 Andres Loeh 5 Chris Wong 5 Iain Nicol 5 Heather 5 Jake Wheat 4 Daniel Trstenjak 4 Tuncer Ayaz 4 Neil Vice 4 Rudy Matela 2 David Feuer 2 Bertram Felgenhauer 2 Fujimura Daisuke 2 Iustin Pop 2 John Chee 2 Keshav Kini 2 Maxwell Swadling 2 Michael Snoyman 2 Owen Stephens 2 Sergey Vinokurov 2 Thomas Miedema 2 Vincent Hanquez 2 jake 1 Brent Yorgey 1 Maximilian Tagher 1 Anton Dessiatov 1 phischu 1 Bob Ippolito 1 Miëtek Bak 1 Bardur Arantsson 1 Nikita Karetnikov 1 tchakkazulu 1 Peter Trško 1 Austin Seipp 1 Ryan Mulligan 1 RyanGlScott 1 Samuel Gélineau 1 Sergei Trofimovich 1 jpmoresmau 1 Simon Hengel 1 Thomas M. DuBuisson 1 Harry Garrood 1 Isamu Mogi 1 kosmikus 1 David Fox 1 Curtis Gagliardi 1 Antonio Nikishaev 1 Karel Gardas 1 Travis Cardwell 1 Chris Allen 1 Matthew William Cox
Hi, sorry that I couldn't test Cabal 1.22 earlier, but there seems to be a change regarding the handling and pretty printing of the 'GenericPackageDescription' in Cabal 1.22. Now parsing a cabal file with 'parsePackageDescription' and pretty printing it with 'showGenericPackageDescription' will result into a cabal file where every section contains the 'build-depends' field twice. Previously the dependencies have been resolved into 'CondNode.condTreeConstraints' and the field 'BuildInfo.targetBuildDepends' has been emptied. Now it seems that both - 'CondNode.condTreeConstraints' and 'BuildInfo.targetBuildDepends' - contain the dependencies and therefore they're output twice. The resolving into 'CondNode.condTreeConstraints' always seemed a bit like a hack to me, because there's already the distiction between 'GenericPackageDescription' and 'PackageDescription', and 'PackageDescription' already represeting the resolved state, so I'm wondering if it wouldn't be best to let 'CondNode.condTreeConstraints' just go, or as a first step, not using it anymore. Greetings, Daniel
Daniel, Can you please file a bug at https://github.com/haskell/cabal/issues so we can track this? On Mon, Jan 5, 2015 at 10:27 AM, Daniel Trstenjak < daniel.trstenjak@gmail.com> wrote:
Hi,
sorry that I couldn't test Cabal 1.22 earlier, but there seems to be a change regarding the handling and pretty printing of the 'GenericPackageDescription' in Cabal 1.22.
Now parsing a cabal file with 'parsePackageDescription' and pretty printing it with 'showGenericPackageDescription' will result into a cabal file where every section contains the 'build-depends' field twice.
Previously the dependencies have been resolved into 'CondNode.condTreeConstraints' and the field 'BuildInfo.targetBuildDepends' has been emptied.
Now it seems that both - 'CondNode.condTreeConstraints' and 'BuildInfo.targetBuildDepends' - contain the dependencies and therefore they're output twice.
The resolving into 'CondNode.condTreeConstraints' always seemed a bit like a hack to me, because there's already the distiction between 'GenericPackageDescription' and 'PackageDescription', and 'PackageDescription' already represeting the resolved state, so I'm wondering if it wouldn't be best to let 'CondNode.condTreeConstraints' just go, or as a first step, not using it anymore.
Greetings, Daniel _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
participants (3)
-
Daniel Trstenjak -
Johan Tibell -
Simon Michael