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. Here's my wishlist (ie. stuff I wish someone, possibly me, would hack on ;-) Are the following planned, possible, far-fetched? ./Setup.hs -n, --dry-run For any command, does not actually do anything (build, install, modify the filesystem), but prints the steps that would be executed (ghc commandlines, install locations etc.) uninstall Removes all files and directories created by install sdist-test 1. runs sdist 2. unpacks the resulting tarball 3. runs configure --prefix=_inst build install (into given _inst) test uninstall 4. Checks that no files remain in _inst 5. Cleans up the source tmpdir 6. If all the above succeed, prints a message saying the tarball is ready for distribution cheers, Conrad.
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. Would it be hard to implement? Anything I could do to help?
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)
Duncan Coutts wrote:
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?
It was possibly because I objected to it; although now I can't remember exactly what it was I diskliked so much about it. Possibly just the fact that I think this is the job of the system's package manager, not Cabal. But the same argument applies to 'setup install' of course. So to be clear, I don't object to uninstall any more, if someone wants to go ahead and implement it that's fine by me. Cheers, Simon
Simon Marlow
Duncan Coutts wrote:
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?
It was possibly because I objected to it; although now I can't remember exactly what it was I diskliked so much about it. Possibly just the fact that I think this is the job of the system's package manager, not Cabal. But the same argument applies to 'setup install' of course.
I don't object to it, though I think it'll be a little tricky, and deleting files in tricky ways is a little scary. It's not a lot tricky or a lot scary :)
So to be clear, I don't object to uninstall any more, if someone wants to go ahead and implement it that's fine by me.
Same here. peace, isaac
Before I start hacking on something I thought I'd do a little survey on the current state of affairs. There's a lot of different stuff "out there" and I'm a bit confused about the purpose of each: * Cabal * cabal-get (dead?) * cabal-install * cabal-put * Hackage * HackageDB I would appreciate if someone could give a short summary of each (with purpose). The picture I got this far is that Cabal is like make but with some extra information (.cabal file) attached so packages can be retrieved from HackageDB. Does this mean that Cabal/Hackage are a bit like Gentoo Portage which fetches and compiles sources? You can probably tell that I'm confused. - Do all these tools work with sources or is there such a thing a binary packaging? - What handles dependencies? - Is there some sort of installed packages DB already (which could be extended with uninstall information)? - Are there any tools for making distribution specific (e.g. deb, rpm) packages?
"Johan Tibell"
Before I start hacking on something I thought I'd do a little survey on the current state of affairs. There's a lot of different stuff "out there" and I'm a bit confused about the purpose of each:
* Cabal * cabal-get (dead?) * cabal-install * cabal-put * Hackage * HackageDB
I would appreciate if someone could give a short summary of each (with purpose). The picture I got this far is that Cabal is like make but with some extra information (.cabal file) attached so packages can be retrieved from HackageDB. Does this mean that Cabal/Hackage are a bit like Gentoo Portage which fetches and compiles sources? You can probably tell that I'm confused.
Good question! I know this is confusing at the moment, as we're still trying to nail it down, but I think we understand it now. Lots of this is in flux right now as we're trying to get together a version of cabal-install (formerly cabal-get) that can actually be installed by a mere mortal. Ironically, we needed cabal-get to install cabal-get. Bah! Anyway, I put a summary of the current state of affiars on the wiki: http://hackage.haskell.org/trac/hackage/wiki/WikiStart Hackage is the name for this entire beautiful mess. '''Hackage Components''': * Cabal: The library, command-line interface, and package description format for a single package. Cabal is the lowest-level tool for Haskell package management. * cabal-setup: A convenience tool for installing a single cabal package. This tool compiles the Setup.lhs script, if necessary, or if there is no Setup.lhs script, it acts like one. This tool is part of the cabal source. * HackageDB: The database of Cabal-ized libraries. Like CPAN for Haskell. This is currently in flux, and so is not really online at the moment. * cabal-install: A tool for installing multiple cabal packages, including downloading packages from HackageDB and determining the dependencies among packages. This tool is in development and not yet available except in the darcs distribution of cabal. It is a part of the cabal source. * cabal-server-install: Not yet available. A tool to be run on hackage.haskell.org for adding packages to HackageDB. * Other Tools * cabal-get: The old version of cabal-install, now defunct. * cabal-put: A client-side version of cabal-server-install; currently defunct. May be resurrected someday.
- Do all these tools work with sources or is there such a thing a binary packaging?
There's not yet any sense of a binary package, but there's not any particularly powerful reason for that. We could immagine this appearing some day if anyone actually wants it enough to implement. I think we should get the source stuff working first, though.
- What handles dependencies?
Dependencies between packages are handled by cabal-install. Dependnecies between modules are handled by ghc --make. It would be very nice to have this in cabal someday.
- Is there some sort of installed packages DB already (which could be extended with uninstall information)?
Maybe the GHC package database (see ghc-pkg), but otherwise, no. Maybe eventually cabal should take over this database functionality, and ghc can ask cabal about packages, or something.
- Are there any tools for making distribution specific (e.g. deb, rpm) packages?
Yes, quite a few. There's one for debian: dh_make, one for rpm: cabal2rpm, and one for gentoo, perhaps others. peace, isaac
participants (5)
-
Conrad Parker -
Duncan Coutts -
Isaac Jones -
Johan Tibell -
Simon Marlow