- cabal-devel - Haskell.org

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

Configure/build separation
by Neil Mitchell 30 Aug '06

30 Aug '06

Hi, First off, being a windows user, having a configure/build separation seems a bit unusual. However, accepting that separation has been chosen, I was wondering what the design rationale for the following behaviour is: I download alex from darcs, runhaskell Setup configure checks for an absolute pile of things - such as alex, c2hs, cpphs - all things that are absolutely not required. In amongst all this waffle, it also checks for Happy - an absolute essential build dependancy. It doesn't find that, like it doesn't find plenty of other things, and continues straight along. Then when I try to buid, it fails. So the two points are: 1) Shouldn't configure check for what is required, rather than everything that any Haskell program might possibly require. 2) Shouldn't failing a configure check be an error, directing you to go get happy? Thanks Neil PS. I'm really liking this Cabal thing, its a very nice concept.

7 8

Plan for cabal-install
by Paolo Martini 28 Aug '06

28 Aug '06

Hello, during AngloHaskell, me, Duncan, Shae and David had the occasion to think about cabal-install (formerly known as cabal-get). The current situation: There is a server-program called cabal-server-install which checks that a given package is valid and updates the index accordingly. Its code can be found here <http://hackage.haskell.org/darcs/cabal-server- install/>. The current index file is a list of {name, description, dependencies, url} informations for each package. The hierarchy of packages and the corresponding index file can be found here <http:// hackage.haskell.org/darcs/cabal-server-install/pub/unstable/>. The problems: The current hierarchy is full of outdate packages, this is easy solvable after we've made some design decisions about the format of the hierarchy and the index file. The current index file format is a made-up format consisting of a certain number of fields, this is a problem because: * Cabal is going to support more dependencies information, like optional dependencies, which will require a field per-se. * For example GUI package managers need to know more than the little information now available after an update command. * The index file contains URL information for each package, which we don't know at the moment of producing that file on the server. A solution to all these problems is having all the `.cabal' files in a tarball as the index file. This is good for a number of reasons, some of those are: * No code is needed to generate the index. One can simple tar the directory hierarchy skipping the tarballs. Now, it will only pack the `.cabal' files; in future, it easily packs all the other files we will eventually need, like `.sig' files for signatures and whatnot. This is a big advantage. * The tarball format is very simple, it is all ASCII, and an Haskell un-tar implementation is very few lines of code, which will be needed for Windows. * Using the `.cabal' files for all the information means that cabal- get is easily {backward,forward}-compatible with changes in the `.cabal' files format, because it just relies on the Cabal parser. (e.g. optional dependencies in the near(?) future.) * We have all the informations from the beginning, after the first `cabal-install update' command. We are quite happy with this solution, but some other decisions need to be made: Now cabal-install saves the server list file in configuration-dir/ serv.lst; the index file in conf-dir/pkg.lst; and downloads all the tarballs in conf-dir/packages/. I'd like to discuss what should the local hierarchy of files look like with this change in the index file format. One problem is that we need to support multiple repositories, and still map the packages to the right URLs. The proposed solution would look like this: We have a conf-dir/repositories/ directory which contains a subdirectories. Those subdirectories are the string-encoded URLs of each repository. They contain the local mirror of the remote hierarchy produced by simply unpacking the index file; it generates a perfect local mirror missing the tarballs. This looks like a sensible nice thing. `cabal-install' will then fetch the informations it needs by looking order-sensitively at the server-list-file, then recurse through the hierarchy finding all the .cabal files. This looks like a pratical solution which should work well until we get thousands of packages. If we ever reach that point and efficiency becomes an issue we could simply load the tarball in memory and play with it lazily, mapping in- memory-cabal-files to records structures with the informations we need. What do you think? Does it look like a good plan? More questions: I am personally not sure about the OutputGen type which is defined in Cabal/Network/Hackage/CabalInstall/Types.hs. It seem to be evil and should be removed. Anybody has a precise idea about it? I have some initial code that makes cabal-get work on the tarball index, but I am not sure about how to integrate with the OutputGen actions, so it is not working now. I need some explanation about it. I hope the contents of this email are understandable, please ask for whatever I have explained badly or I have assumed for some reason. Peace, Paolo. --

5 5