- cabal-devel - Haskell.org

Keeping the cabal website in the git repo
by Johan Tibell 08 Sep '13

08 Sep '13

Hi all, While the sources of some of the documentation is already in git, much of the website (http://www.haskell.org/cabal/) isn't. I suggest we check it in under a website/ directory, next to the Cabal and cabal-install directories. -- Johan

3 2

Re: [Haskell-cafe] ANN: Cabal v1.18.0 released
by Johan Tibell 05 Sep '13

05 Sep '13

I pasted your report into the bug tracker: https://github.com/haskell/cabal/issues/1478 I don't know if you're on GitHub or not so I could link the report to your user. On Thu, Sep 5, 2013 at 8:16 AM, Rogan Creswick <creswick(a)gmail.com> wrote: > I ran into another oddity due to old build artifacts today -- it was easy to > fix, but very confusing; cabal repl was exiting with "unrecognised command: > repl". > > tl/dr; if you see this, delete the old 'dist' dir and re-run 'cabal > configure'. > > Here's a snippit of my shell session to explain in more detail: > > $ cabal sandbox init > ... > $ cabal --version > cabal-install version 1.18.0 > using version 1.18.0 of the Cabal library > $ cabal configure > Resolving dependencies... > Configuring pgftransform-0.0.0.1... > $ cabal repl > unrecognised command: repl (try --help) > $ cabal --help > ... > Commands: > ... > build Compile all targets or specific targets. > repl Open an interpreter session for the given target. > sandbox Create/modify/delete a sandbox. > ... > > Note that cabal --version and cabal --help indicated that repl /was/ a valid > command. > > The issue appears to be that an old dist directory was still hanging around, > and (I suspect) the compiled setup.hs build program (which would have been > built with an old Cabal) was causing the actual error. Deleting the dist > dir and re-running cabal configure set everything right. > > --Rogan > > > On Thu, Sep 5, 2013 at 6:18 AM, Yuri de Wit <ydewit(a)gmail.com> wrote: >> >> It is easy enough to recreate the link manually or as easy to run cabal >> install again, but that is not the point here. The point is that it will >> bite the next dozen of unsuspecting users since, at first, they have no idea >> of what is going on. >> >> In any case, apologies for sending this in this thread as it doesn't seem >> the right forum to discuss it. >> >> >> On Thu, Sep 5, 2013 at 7:53 AM, Paolo Giarrusso <p.giarrusso(a)gmail.com> >> wrote: >>> >>> On Wednesday, September 4, 2013 11:41:33 PM UTC+2, Yuri de Wit wrote: >>>> >>>> Thanks for all the hard work! >>>> >>>> If you see this in OSX (#1009) while installing cabal 1.18: >>>> >>>> Warning: could not create a symlink in /Users/lemao/Library/Haskell/bin >>>> for >>>> cabal because the file exists there already but is not managed by cabal. >>>> You >>>> can create a symlink for this executable manually if you wish. The >>>> executable >>>> file has been installed at >>>> /Users/user/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.18.0/bin/cabal >>>> >>>> You will need to manually remove the pre-existing 1.16 links in >>>> ~/Library/Haskell/bin before installing again. >>> >>> >>> Instead of installing again, you can even just recreate the symlink as >>> mentioned by the message (if you know how to do that). >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Re: [Haskell-cafe] ANN: Cabal v1.18.0 released
by Yuri de Wit 05 Sep '13

05 Sep '13

It is easy enough to recreate the link manually or as easy to run cabal install again, but that is not the point here. The point is that it will bite the next dozen of unsuspecting users since, at first, they have no idea of what is going on. In any case, apologies for sending this in this thread as it doesn't seem the right forum to discuss it. On Thu, Sep 5, 2013 at 7:53 AM, Paolo Giarrusso <p.giarrusso(a)gmail.com>wrote: > On Wednesday, September 4, 2013 11:41:33 PM UTC+2, Yuri de Wit wrote: > >> Thanks for all the hard work! >> >> If you see this in OSX (#1009) while installing cabal 1.18: >> >> *Warning: could not create a symlink in /Users/lemao/Library/Haskell/bin >> for* >> *cabal because the file exists there already but is not managed by >> cabal. You* >> *can create a symlink for this executable manually if you wish. The >> executable* >> *file has been installed at* >> */Users/user/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.18.0/bin/cabal >> * >> >> You will need to manually remove the pre-existing 1.16 links in >> ~/Library/Haskell/bin before installing again. >> > > Instead of installing again, you can even just recreate the symlink as > mentioned by the message (if you know how to do that). >

1 0

Patch for Cabal
by Dominic Steinitz 02 Sep '13

02 Sep '13

Hi Duncan, I finally finished off the patch for https://github.com/haskell/cabal/issues/1460 I was working on with your help at ZuriHac. It's in my fork of cabal here: https://github.com/idontgetoutmuch/cabal/commit/f76ab8b6c0945b82746d664918e… I am not sure what to do next. How should we test it? We need to make sure it doesn't break anything and also that it actually fixes the problem. Curses! I just forgot I don't check which version of cabal is being used so that we pass the old style --constraint rather than the new style --dependency for old cabals. Before I fix that, perhaps you wouldn't mind thinking about testing and also have a look at the code to make sure I haven't done something stupid. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

Re: Setting up a build bot
by Johan Tibell 31 Aug '13

31 Aug '13

I've been running a Jenkins build bot for cabal for quite a while: http://ci.johantibell.com/job/cabal/ It's not as good as it could be, because the Cabal test suite isn't in the best shape. In particular the InternalLibrary tests are failing at the moment and I think it's because the tests actually modify the shared package DB (i.e. the user DB)! If you could figure out why they're failing and/or make the test suite more robust (i.e. it should create a new empty package DB every time) that would be great. On Sat, Aug 31, 2013 at 9:43 AM, Paolo Giarrusso <p.giarrusso(a)gmail.com>wrote: > Hi all, > I'm at Zurihac and I'm experimenting with setting up Travis > integration for cabal (I've never used Travis before); Duncan Coutts > told me to coordinate with you, since you've been also thinking about > this. > > I'm also trying out using Ceh (presented at this ZuriHac itself, > presentation visible by downloading > > https://github.com/errge/ceh/blob/master/doc/fpafternoon-zurich-20130829/fi… > ) > to get an updated Haskell version (rather than the default Haskell > platform from last year); if this works, we can maybe try out testing > cabal on different versions. > > I'll keep playing with this for a while. > Comments and suggestions are welcome! > > Cheers, > Paolo > > -- > Paolo G. Giarrusso - Ph.D. Student, Philipps-University Marburg > http://www.informatik.uni-marburg.de/~pgiarrusso/ >

3 2

Cabal/cabal-install 1.18 RC2
by Johan Tibell 30 Aug '13

30 Aug '13

Hi, I've prepared another RC, including some fixes. This one is based on 9f374ab45e62924506b992db9157c970c7259a03 on the master branch. If we don't see any problems with this RC the next few days, I'll release it as 1.18. Again, to install the RC just run: cabal install http://johantibell.com/files/Cabal-1.18.0-rc2.tar.gz http://johantibell.com/files/cabal-install-1.18.0-rc2.tar.gz These are the changes since RC1: 9f374ab Give the xxx_HOST_OS and xxx_HOST_ARCH options that were probed from ghc's target platform, rather than assuming HOST == BUILD. This fixes things for cross compiling. 0bd367f Fix the 'index.cache' up-to-date check. 323460e Unit tests: use configure GHC 473f76a Merge pull request #1440 from 23Skidoo/ghc-info-ignore-ghc-options 85cb83d Merge pull request #1441 from 23Skidoo/repl-extralibs 2d938de Rename 'pref' to 'libTargetDir'. d9283d2 Rearrange the code a bit. 7802fa0 Ignore 'ghc-options' when parsing 'ghc --info' output. 218c6bb Add 'suppressOverrideArgs'. 43624cf Formatting. a3bbf4c Pass linker options when loading *libraries* in GHCi. c977ddd Merge changes from GHC HQ fork 5fa5c41 Merge branch 'master' into roles dd3ca38 Fix link to users' guide. 2803d87 Added a new extension (RoleAnnotations) to the list -- Johan

5 6

Cabal-1.18.0 and cabal-install-1.18.0 release candidates (please test)
by Johan Tibell 28 Aug '13

28 Aug '13

Hi all, We're close to a new release of Cabal/cabal-install and I'd appreciate some help in testing the new release. To install the release candidate, simply run: cabal install http://johantibell.com/files/Cabal-1.18.0.tar.gz http://johantibell.com/files/cabal-install-1.18.0.tar.gz Please try on different OSes if you have several available. Report bugs at https://github.com/haskell/cabal/issues *Things to try* This is not a complete list of new features (and bugs fixed)! *Sandboxing* Sandboxes help prevent "dependency hell" by having each project you're working on use a separate package database to install its dependencies in. Try it out on one of your projects like so: cd my-pkg cabal sandbox init # only once cabal install --only-dependencies cabal configure cabal build *GHCi support* The new cabal repl commands lets you load up your library inside GHCi without lots of command line fiddling. Just run cabal repl instead of cabal build and play around without your library. *Known issues to be fixed before release* https://github.com/haskell/cabal/issues/1439 Cheers, Johan

2 2

Gearing up for a 1.18 release
by Johan Tibell 26 Aug '13

26 Aug '13

Hi all, The sandbox functionality now works well enough that I think we should let it out in the wild. I've created a 1.18 release branch at https://github.com/haskell/cabal/tree/cabal-install-1.18 My intention is to make any necessary bug fixes on that branch before the release and then merge those fixes into master once the release is done (i.e. using a work flow similar to http://nvie.com/posts/a-successful-git-branching-model/ but without the develop branch). Are there any fixes that absolutely must make it in before a 1.18 release? Remember, this release is already long overdue and there will be more frequent releases in the future so lets not try to cram in some extra functionality and delay this release further. P.S. In the future I hope we can make a release every 3-6 months instead of the current almost yearly release cycle. Cheers, Johan

7 27

Cabal Hacking at ZuriHac 2013
by Dominic Steinitz 25 Aug '13

25 Aug '13

Hi All, I and a small team hacked on Cabal at OdHac earlier this year (http://www.haskell.org/haskellwiki/OdHac/Projects#Cabal) I am going to ZuriHac (http://www.haskell.org/haskellwiki/ZuriHac2013) next week and will carry on going through the issues list (https://github.com/haskell/cabal/issues?labels=&milestone=&page=1&state=open) But let me know if there are any items that people would really like implemented / fixed and I (we) can work on those. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

GHCJS support for Cabal
by Luite Stegeman 23 Aug '13

23 Aug '13

hi all, We're readying the GHCJS [1] compiler for the first release, to coincide with GHC's 7.8.1 release. For now, GHCJS is a stand-alone executable that uses the GHC API and manages its own package database. We've been maintaining a Cabal patch with the intention to get it merged in 1.18, but now that release appears to be earlier than I expected (thanks Carter for warning me!) The current diff is here (the js-sources / extra-js-files field additions would be left out for 1.18, and some of the Distribution.Simple.GHC module changes can be cleaned. Give me a few days if you want a full patch for review): https://github.com/ghcjs/cabal/compare/ghcjs I'm not sure if it's still feasible to get the whole thing in (I have time to hack on it the coming weeks and can discuss at ZuriHac) 1.18, but if not, there are some very small parts that change the API a bit, that could perhaps go in 1.18, postponing full GHCJS support to 1.18.1 or similar. Does that sound reasonable? Overview of the changes: 1. CompilerId gets an extra field, indicating that compiler x is based on compiler y. Both compilers have their own version. impl(x >= x-version), impl(y >= y-version) flags would both be true for this flavor. (This is the public API change). GHCJS is added as a compiler flavor 2. Support for the GHCJS flavor is plumbed throughout Cabal 3. The Distribution.Simple.GHC module exports internal functions, some of those are modified so the program can be passed in explicitly. For most things, the Distribution.Simple.GHCJS module calls back to the GHC module pretending to have the version of the underlying GHC. 1. changes existing API a tiny bit, so that would be nice to go in 1.18 if still possible. 3. is a bit messy, but doing it this way appears to avoid by far the most code duplication. Perhaps some restructuring of the GHC module would make it better, then it could be done without touching exported API. I'd be happy to hear comments or suggestions and clean it up a bit. luite [1] https://github.com/ghcjs

2 2