- cabal-devel - Haskell.org

Re: [Hackage] #155: show . readPackageDescription /= id
by Hackage 11 Apr '08

11 Apr '08

#155: show . readPackageDescription /= id ----------------------------------------+----------------------------------- Reporter: kolmodin(a)dtek.chalmers.se | Owner: nominolo Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ----------------------------------------+----------------------------------- Changes (by nominolo): * status: assigned => closed * resolution: => wontfix Comment: This will never be possible in general. We can try {{{showPD . readPD . showPD . readPD == readPD}}}. Closing as wontfix. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/155#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: nice little Cabal gotcha
by Duncan Coutts 09 Apr '08

09 Apr '08

Peter, BTW, do file a bug report describing this issue so we do not forget. If you want to include my two suggestions then you could link it to the ticket aboug making cabal/cabal-install remember what files it installs. Duncan On Mon, 2008-04-07 at 18:37 +0700, Peter Gammie wrote: > Imagine this: you're hacking a library, and occasionally you put a "- > p" on your config line and sometimes you don't. > > (My cycle is occasional-clean-setup then build, which I grant might be > a bit paranoid. I get impatient and fiddle with the profiling and > optimisation options.) > > Now, if one compiles a library with "-p", then without it, the old > profiling library persists in the installed location, leading to some > head scratching when a later compilation with a "-p" config option > mysteriously fails. > > Two proposals: > > - rm -r $INSTALL_LOCATION (e.g. ~/lib/package/) > (brutal but effective; I think Cabal should claim ownership of at > least the package subdirs that it will populate) > - print "Compiling normally..." and "Compiling for profiling..." to > make it clearer when the compilation craps out > > I guess you'll be squeamish about the first one, but I for one would > like such an option when hacking. > > cheers > peter

1 0

Re: nice little Cabal gotcha
by Duncan Coutts 09 Apr '08

09 Apr '08

Hi Peter, On Mon, 2008-04-07 at 18:37 +0700, Peter Gammie wrote: > Imagine this: you're hacking a library, and occasionally you put a "- > p" on your config line and sometimes you don't. Yep. And Cabal doesn't track if the profiling versions of dependencies are installed. > (My cycle is occasional-clean-setup then build, which I grant might be > a bit paranoid. I get impatient and fiddle with the profiling and > optimisation options.) > > Now, if one compiles a library with "-p", then without it, the old > profiling library persists in the installed location, leading to some > head scratching when a later compilation with a "-p" config option > mysteriously fails. You mean because the old version of the profiling lib is installed but it does not match the newer non-profiling version? So building a dependent lib with -p fails with weird complication errors? > Two proposals: > > - rm -r $INSTALL_LOCATION (e.g. ~/lib/package/) > (brutal but effective; I think Cabal should claim ownership of at > least the package subdirs that it will populate) > - print "Compiling normally..." and "Compiling for profiling..." to > make it clearer when the compilation craps out We could easily do the latter. > I guess you'll be squeamish about the first one, Yep :-) > but I for one would like such an option when hacking. There are two ways we could do it, one is to make it possible to build several related packages without installing them all, then we have complete control over what is in the dist/ dir and we know when the profiling versions of libs are out of date. Another way is for cabal-install to gain more package management features and remember what files belong to a package, so then we can uninstall packages and when we replace packages we can remove all files belonging to the existing instance of that package. Duncan

1 0

Cabal partial builds
by Peter Gammie 09 Apr '08

09 Apr '08

Hello, Is it possible to ask Cabal to just build one of the targets in the .cabal file? I have a bunch of executables in a single file, most of which are uninteresting while developing. I'd like to say: runghc Setup build blah and have "blah" built (and its dependencies, when you have the framework) but not blah2 etc. cheers peter

2 2

[GSoC] Cabal 'make-like' dependency framework
by Max Desyatov 07 Apr '08

07 Apr '08

Hi, There are only few hours until the deadline, but I still have some hope to receive comments to improve my proposal. The goal of the project I am intending to do is to develop a working prototype of a make-style module/file dependency framework for the Cabal, which is the most actively evolving Haskell build system at the moment. At this time building process with Cabal is somewhat imperative and depends on GHC's "--make" option or hmake when building modules written in the Haskell language. Thus, new dependency system should support its own module chasing from a description given the declarative style, which would give a possibility to add many new features and resolve old bugs in the Haskell Cabal (as there are currently more than 10 tickets which depend on the dependency tracking implementation). Pre-processors (c2hs e.g.) and some other Haskell compilers, which don't have their own dependency system, would greatly benefit from this improvement. Gtk2hs will also greatly benefit from this project, as at this time it uses shell language and limited functional language on top (make) for its build system which prevents handling of dynamic dependencies in the right way. Absence of dependencies tracking in Cabal prevents gtkhs to be cabalised fully. Getting some ideas from the first sketchy prototype we can see that dynamic dependencies should be supported, i.e. some actions can be run while computing the dependency graph. The plan to deploy the code of the project in the real use cases is to code dependency resolver for yhc or nhc98 (depends on the difficulty of integration with existing compiler codebase). Doing this won't hurt ghc support, which is quite important. The great part of the work is contriving an embedded domain specific language for the make actions specification. This will reduce complexity, role of imperative parts and code size of Cabal in general. The form of this EDSL needs careful investigation. The system should be fairly generic and extensible for actions and rules to be expressed crearly. Framework can be customised with pre-processors or other actions which are run in the process of the dependency resolving. For the aid in testing and clarifying project goals some sophisticated examples will be constructed (using pre-processors, cases with search path shadowing etc). Seeing the existing problems we can decide how to improve Cabal for their resolution. With the help of parametrisation over a type of used monad for actions we can do tests without any IO through QuickCheck. Do you think there are some things in this abstract I should remove or I should definitely add? Are there some wrong assumptions or things that can go beyond my project? Thanks for advance for any advice, comment or question. -- Max

1 0

Cabal, profiling, GHC 6.6.1
by Peter Gammie 07 Apr '08

07 Apr '08

Hello, I've built some libraries using "-p" and installed them, resulting in e.g.: mjollnir-debian ~$ ls ~/lib/hsql-postgresql-1.7/ghc-6.6.1/ Database HShsql-postgresql-1.7.o include libHShsql-postgresql-1.7.a libHShsql-postgresql_p-1.7.a When I try to use them: mjollnir-debian ~$ ghc -prof -auto-all -Wall -fglasgow-exts -main- is Import.News.main --make -o news ghc_rts_opts.c Import.News [..] Linking news ... /usr/bin/ld: cannot find -lHShsql-postgresql-1.7_p collect2: ld returned 1 exit status make: *** [news] Error 1 Note that Cabal created "libHShsql-postgresql_p-1.7.a" but GHC expected "libHShsql-postgresql-1.7_p.a". Is this an issue with GHC 6.6.1 or Cabal? cheers peter

2 2

patch applied (cabal-branches/cabal-1.4): Fix names of profiling libs
by Duncan Coutts 07 Apr '08

07 Apr '08

Sun Apr 6 18:34:49 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix names of profiling libs I broke this recently when refactoring. Restore the original behaviour. Was generating "libHSfoo_p-1.0.a" when it should be "libHSfoo-1.0_p.a". M ./Distribution/Simple/BuildPaths.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008040701…

1 0

patch applied (cabal): Fix names of profiling libs
by Duncan Coutts 07 Apr '08

07 Apr '08

Sun Apr 6 18:34:49 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix names of profiling libs I broke this recently when refactoring. Restore the original behaviour. Was generating "libHSfoo_p-1.0.a" when it should be "libHSfoo-1.0_p.a". M ./Distribution/Simple/BuildPaths.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080407013449-adfee-dbba5be8…

1 0

ANNOUNCE: Cabal-1.4 release candidate
by Duncan Coutts 06 Apr '08

06 Apr '08

Hi everyone, == Cabal-1.4 release candidate == The first release candidate of Cabal-1.4 is out: http://haskell.org/cabal/release/cabal-1.3.10/Cabal-1.3.10.tar.gz Please test and report bugs: http://hackage.haskell.org/trac/hackage/ The aim for the Cabal-1.4 release is to get various fixes and improvements into the hands of developers and to support a release of cabal-install. == cabal-install == A snapshot of cabal-install is available: http://haskell.org/cabal/release/cabal-install-0.4.6.tar.gz It requires the zlib and HTTP packages (both are available from hackage). Bug reports should go in the same trac as above. cabal-install is intended to be the standard command line interface to the whole Cabal/Hackage system. It replaces the "runhaskell Setup.hs" interface and a few other tools you may or may not have heard of (cabal-setup, cabal-upload, cabal-get). cabal-install is usable now and we will be making a proper release some time after the Cabal-1.4 release. == Compatibility == We have tried to preserve compatibility with all packages that worked with the Cabal-1.2.x series. That is, packages that can be built using Cabal (including custom Setup.hs scripts) but not packages that directly import and use the Cabal API. Packages that directly import and use the Cabal api will need updating. This affects packages that build distro packages for example, rpm debs etc. Currently we know of three packages on hackage where their Setup.hs scripts compile with 1.2 but fail to compile with 1.4. We expect to make one further change before the Cabal-1.4 release that will fix two of those packages. The one remaining package, Takusen, will require an update to be able to work with both Cabal-1.2.x and 1.4.x. A patch has been sent to the maintainers of Takusen. == Remaining issues == There are a couple issues we expect to fix before the Cabal-1.4.0 release: * stricter decoding of UTF-8 in .cabal files (we'll borrow the code from the utf8-string package) * compatibility with the couple Setup.hs scripts that use the function Distribution.PackageDescription.writeHookedBuildInfo There are also a few bug fixes and enhancements we think we can probably do in the 1.4.x stable series without breaking any APIs: http://hackage.haskell.org/trac/hackage/query?status=new&status=assigned& status=reopened&group=component&milestone=Cabal-1.4&order=priority == Credits == On behalf of the Cabal hackers and the community generally I'd like to thank the large number of people who have contributed patches during this development series. Previously I was rather worried that we were not getting enough contributors to fix bugs and do new feature development, but now I'm very pleased. :-) == Get involved == Of course there's still a lot to do! We have big plans for Cabal-2.0, cabal-install and the Hackage website. So if you're interested in helping out with this core infrastructure project then: * subscribe to the cabal-devel mailing list: http://www.haskell.org/mailman/listinfo/cabal-devel * grab the source: http://haskell.org/cabal/code.html * read the guide to the source code: http://hackage.haskell.org/trac/hackage/wiki/SourceGuide * take a look at our list of bugs and feature requests: http://hackage.haskell.org/trac/hackage/report/12 especially the easy tickets: http://hackage.haskell.org/trac/hackage/report/13 Duncan (wearing his Cabal release manager hat)

2 2

patch applied (cabal-install): Add missing modules in other-modules, fixes sdist
by Duncan Coutts 05 Apr '08

05 Apr '08

Sun Mar 30 12:37:10 PDT 2008 Spencer Janssen <sjanssen(a)cse.unl.edu> * Add missing modules in other-modules, fixes sdist M ./cabal-install.cabal +3 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080330193710-a5988-…

1 0