September 2006 - cabal-devel

Re: cabal (./Setup.hs) options
by Duncan Coutts 05 Dec '06

05 Dec '06

On Tue, 2006-08-08 at 10:45 +0200, Johan Tibell wrote: > > Hi, > > > > I like Cabal. There are a few things that I'm used to from autotools which > > I can't seem to find: dry-runs, uninstall and a "make distcheck" equivalent. > > <snip> > > > uninstall > > Removes all files and directories created by install > > Ditto. This is really necessary since otherwise I'll have to build a > Debian package anyway before I can install the Cabal package. Getting > software of my system is almost as important as getting it on there in > the first place. Prevents my system from deteriorating over time. I think we didn't include this feature deliberately for some reason. Isaac can you remember? > Would it be hard to implement? Anything I could do to help? In general the way to help is just to submit patches with an accompanying explanation/motivation/rationale. 'darcs send' does the "Right Thing"tm, i.e. it sends them to the cabal-devel list. Oh and everyone is invited to join the cabal-devel mailing list. Subscribe here: http://www.haskell.org/mailman/listinfo/cabal-devel Our main bottleneck on Cabal development is not the lack of people pointing out shortcomings but the number of people sending patches. Send more patches, the last ones tasted great! Duncan (wearing his Cabal patch reviewer hat)

8 12

sof patch for --ghc-pkg-config-file=
by Isaac Jones 29 Sep '06

29 Sep '06

Emailing to libraries@, please followup to cabal-devel. Here's a patch from Sigbjorn which adds --ghc-pkg-config-file= to cabal. This is an oldish patch, but I haven't stopped getting requests for this feature :) This allows you to create a "local" package config file, rather than using the --user or --global files, this is useful for in-place building, as when you're developing a set of related packages. I still have some debate about whether this patch should go in; it assumes a model of package registration where you have a config file (as opposed to a directory) which isn't the case for nhc or Hugs. But the idea doesn't seem to bother anyone but me, and the flag is clearly marked as a ghc-related flag, so I'm thinking of letting it through. Opinions? Does anyone want to massage this to work w/ the current cabal head? peace, isaac ------------------------------------------------------------ Changed paths: M /Distribution/Make.hs M /Distribution/Setup.hs M /Distribution/Simple/Build.hs M /Distribution/Simple/Configure.hs M /Distribution/Simple/GHCPackageConfig.hs M /Distribution/Simple/Install.hs M /Distribution/Simple/LocalBuildInfo.hs M /Distribution/Simple/Register.hs M /Distribution/Simple.hs M /tests/ModuleTest.hs A couple of extensions: - support for specifying what GHC package configuration file to use during (un)registration. Specified via the command-line option --ghc-pkg-config-file=<path> which is understood by 'configure', 'install', 'register', and 'unregister' commands. - better handling of package-specific header files during installation. If you use the Include-Dirs: and Includes: fields in your .cabal file to refer to package-local header files and directories, these will be created&copied during 'install'. i.e., suppose you spec the following: Include-Dirs: /usr/local/include/openssl, include Includes: include/openssl-exts.h, +openssl/openssl.h The 'install' action will emit the following ghc-pkg fields when updating/installing the GHC package: include_dirs = [ "/usr/local/include/openssl", "/path/to/your/pkg/installation/lib/directory/include"] c_includes = [ "openssl-exts.h", "openssl/openssl.h"] and creates the directory in include_dirs's second element, followed by copying openssl-exts.h into that directory. Note: - only directories that don't start with '/' are created inside the package's install directory. - Includes: entries that are prefixed with '+' are assumed to be referring to non-package header files and aren't (attempted) copied into the package's installation tree. Bit of a twiddly hack, but supporting the distinction between package and non-package header files does seem to be necessary.

4 6

how to implement uninstall & Logging paths of installed files?
by Isaac Jones 20 Sep '06

20 Sep '06

> On 9/16/06, Isaac Jones <ijones(a)syntaxpolice.org> wrote: >> "Johan Tibell" <johan.tibell(a)gmail.com> writes: >> >> > I'm trying to write a module that logs all files installed by Cabal to >> > a file. I've looked through parts of the source and conclude that some >> > of the information (the one used to generate prefixes) needed to >> > construct absolute file paths for installed files exists in >> > Distribution.Simple.LocalBuildInfo. Where does the actual copying take >> > place and is there a way to list the files being copied or am I better >> > of trying to list all files in the dist/ dir and prepend the prefixes >> > myself? What code decides how files are laid out in dist/? Hi all, FWIW, Johan is still interested in this. I would look especially at the "copy" and "install" commands. Look at Distribution.Simple.Utils, lots of "copy" related functions in there. Look especially at the "prefix" type parameters. The Distribution.Simple.Install.install function also implements the "copy" command; so "install" is more general, the prefix is all that changes, so look especially at this function. Look at the copydest parameter. Someone (else?) was looking into writing an "uninstall" feature, which would log the files installed so that it could remove them later. I think that logging & uninstall could be implemented quite effectively by tweaking the "install" target so that it first copies stuff into a temporary location, then uses a "find" type algorithm to discover all of the files that are meant to be installed. The find algorithm would create this list of files and dump it to a log. It would then use a recursive copy algorithm to copy all of these files into place. (The copy command would do pretty much the same, but skip the copy-in-place step.) The recursive copy function would have to not freak out if the directories already exist, of course. Install should also install this "log" of files somplace (where?), for the sake of uninstall. How's that sound? peace, isaac

2 3

Re: please try this tiny script to test cabal-install
by Isaac Jones 16 Sep '06

16 Sep '06

"Jason Dagit" <dagit(a)codersbase.com> writes: > The script test-cabal-install fails with this messages: > ./setup build > setup: Warning: The field "hs-source-dir" is deprecated, please use > hs-source-dirs. > Preprocessing executables for cabal-install-0.3.0... > Building cabal-install-0.3.0... > Chasing modules from: src/CabalInstall.hs > Could not find module `Distribution.Compat.FilePath': > it is hidden (in package Cabal-1.1.5) > (imported from src//Network/Hackage/CabalInstall/Install.hs) > make: *** [build] Error 1 > > The reason for this error is that cabal does not set the permissions > on freshly installed librarys correctly on my machine. I don't know > why this is the case, but I can provide information about my setup. Thanks for the report! I think that this has already been fixed with the new cabal release. Is that so, Duncan? We had thought to hide FilePath, but it's apparently too popular to keep from the people. peace, isaac

2 1

please try this tiny script to test cabal-install
by Isaac Jones 16 Sep '06

16 Sep '06

Paolo has been hacking on cabal-install, as many of you know. Cabal-install is a tool for installing cabal packages and their dependencies. We put together this little script that _should_ just install cabal-install, along with testing it out to install hnop. I know this works on my Debian box, your results may vary, especially if you don't use sudo, but these commands should be pretty clear for you to try them yourself. Please copy and paste this into a terminal, or make minor tweaks and do the same. Email cabal-devel to let us know if it worked or if it didn't! wget http://hackage.haskell.org/~paolo/darcs/cabal-install/test-cabal-install && chmod 755 test-cabal-install && ./test-cabal-install (Now that you've got that working, you can "cabal-install list" and see the packages on the server.) peace, isaac p.s. of course, if you don't trust hackage or paolo, you should look at the code before you run it as root ;) p.p.s. the script itself, in case you want to copy, mod, and paste is: #!/bin/sh darcs get http://hackage.haskell.org/~paolo/darcs/cabal-install/ && \ cd cabal-install && \ make && \ sudo make install && \ sudo cabal-install update && \ cabal-install install --prefix=/tmp --user hnop && \ ls -l /tmp/bin/hnop

1 0

3rd Cabal-1.1.6 release candiate
by Duncan Coutts 13 Sep '06

13 Sep '06

Hi all, I've put up a tarball for the third 1.16 Cabal release candidate: http://www.haskell.org/cabal/release/cabal-1.1.5.9.3/cabal-1.1.5.9.3.tar.gz This is also included with very recent GHC 6.5 snapshots. Please test this with your packages and report any issues to cabal-devel(a)haskell.org We're particularly interested of course in anything that worked before and is now broken. Duncan

1 0

Build failures in packages built with GHC 6.6
by Duncan Coutts 11 Sep '06

11 Sep '06

Hi folks, Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell packages with the latest GHC 6.6 RC snapshot. Here is his report of what failed, and how: http://www.haskell.org/~gentoo/gentoo-haskell/projects/GHC-6.5-failures.html You'll note that there are some common ones, like Data.FiniteMap going away and the old API in Data.Set disappearing. There seemed to be several programs which used the old lang or text packages. The change in the array bounds api broke some things. Text.Regex moved into a different package. Most of these look fairly trivial. Class instance changes broke a couple packages, which might be a bit more tricky to fix. One Cabal api change broke one package, again easily fixable. We made some Cabal modules that had been private by convention properly private (ei Distribution.Compat.*). This broke lhs2tex. I'm not sure exactly what Cabal scripts should be using for portable file path handling since Setup.hs modules are not supposed to have external dependencies on other packages (otherwise there's a chicken and egg problem with compiling Setup.hs). Advice here would be apreciated, I could let Distribution.Compat.FilePath remain public in this release and seek a better solution for the next release. BTW, you can see the complete set of Gentoo's Haskell packages here: http://www.haskell.org/~gentoo/gentoo-haskell/ (mostly under dev-haskell/) Gentoo users & developers can use this package collection as a portage overlay. Duncan (wearing his Cabal release manager hat and his Gentoo hat)

1 0

Repositories
by Paolo Martini 03 Sep '06

03 Sep '06

Hello, I've published a number of repositories so that people can try cabal- install more easily, I need to know wether it's working for you too, and what are the important things to do to towards the goal of shipping it with ghc-6.6. My Cabal repository: <http://hackage.haskell.org/~paolo/darcs/Cabal/> Patches (applied in the above repository): <http://hackage.haskell.org/~paolo/tmp/cabal-install-tarball- index.patch> <http://hackage.haskell.org/~paolo/tmp/cabal-install- dependencies.patch> Packages repository: <http://hackage.haskell.org/~paolo/darcs/packages/> Some of the notable programs in the packages repository, if you are thinking about testing it out: * hnop (!) * lambdabot (!) * darcs-graph * hmp3 * hask-home * many of the dependencies of Hope (<http://hope.bringert.net/>), but no HaskellDB, any version available? * ...etc, darcs send me packages if you please. Issues & ideas: * some packages miss the brief synopsis * no multiple repositories are allowed (I am thinking about how to solving it, ideas are welcome) * should it work on windows for ghc-6.6? * the dependency resolution code seem to work, but it should be probably "audited" better * you ideas? Peace, Paolo. --

2 1

darcs patch: Added c2hs dependency resolver
by Lennart Kolmodin 02 Sep '06

02 Sep '06

Fri Sep 1 19:19:57 CEST 2006 Lennart Kolmodin <kolmodin(a)dtek.chalmers.se> * Added c2hs dependency resolver

1 0