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
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.
Great! Having the system's package manager take care of packaging has not work well for the Ruby on Rails community (with Ruby Gems). Lots of Gems are either missing or outdated since the system's package maintainers can't keep up with the explosion of Gems. I often find myself in need of the latest version of a Cabal package (right now I need the latest HTTP) only to discover that it won't be available until the next release of my distribution (in this case Ubuntu Edgy).
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
The current directory structure under 'dist/build' does not allow for sharing source code on multiple machines. I thought it would be a good idea to insert a directory layer for the target machine. Then I can use the same sources and haddock files on multiple machines which mount the same filesystem. Cabal could create, say dist build Linux-ix86 Linux-PPC Solaris-ix86 Solaris-MIPS doc html .
lemming:
The current directory structure under 'dist/build' does not allow for sharing source code on multiple machines. I thought it would be a good idea to insert a directory layer for the target machine. Then I can use the same sources and haddock files on multiple machines which mount the same filesystem. Cabal could create, say
dist build Linux-ix86 Linux-PPC Solaris-ix86 Solaris-MIPS doc html
.
Yes, good idea. OpenBSD's package system allows this kind of thing. -- Don
If a project consists of both a library and executables, the library modules are re-compiled for each executable. (I use GHC.) That leads to high space and time consumption. Is this a bug or a feature?
Hi
If a project consists of both a library and executables, the library modules are re-compiled for each executable. (I use GHC.) That leads to high space and time consumption. Is this a bug or a feature?
I also note that if a cabal project contains two programs which share code, then this code is recompiled twice on each change. Thanks Neil
Neil Mitchell wrote:
If a project consists of both a library and executables, the library modules are re-compiled for each executable. (I use GHC.) That leads to high space and time consumption. Is this a bug or a feature?
I also note that if a cabal project contains two programs which share code, then this code is recompiled twice on each change.
Compiling twice is the safe thing to do. Sharing the object files is only possible if the object code really would be the same if it was recompiled; there are various things that could prevent that being true, for example if flags change or modules lower down the dependency tree have changed. I'm sure it's possible to do this, but AFAIK nobody has put any thought into figuring out when it's safe to do it. If you share code between executables, the right thing to do is to put it in a library (I realise that when the amount of code shared is small it doesn't seem worthwhile to create a whole package, though). Cheers, Simon
Henning Thielemann wrote:
If a project consists of both a library and executables, the library modules are re-compiled for each executable. (I use GHC.) That leads to high space and time consumption. Is this a bug or a feature?
A package that has both a library and executables isn't supported well right now, and in fact the intention is to deprecate and remove it. Actually I'm surprised if it works at all. The right way is to have a separate package to contain the library code, and depend on this package for your executables. Cheers, Simon
On Mon, 4 Dec 2006, Simon Marlow wrote:
Henning Thielemann wrote:
If a project consists of both a library and executables, the library modules are re-compiled for each executable. (I use GHC.) That leads to high space and time consumption. Is this a bug or a feature?
A package that has both a library and executables isn't supported well right now, and in fact the intention is to deprecate and remove it. Actually I'm surprised if it works at all.
The right way is to have a separate package to contain the library code, and depend on this package for your executables.
Sounds good. Btw. that's the way the Modula-3 build system handles packages. Ask Luca Cardelli in Cambridge! :-) Maybe the attached executables are the interim solution until "the right thing" (compiling multiple packages easily) is implemented.
participants (8)
-
dons＠cse.unsw.edu.au -
Duncan Coutts -
Henning Thielemann -
Isaac Jones -
Johan Tibell -
Neil Mitchell -
Simon Marlow -
Simon Marlow