On Wednesday 06 October 2004 09:37 am, Ian Lynagh wrote:
[dropped the cabal ITP bug from CC list]
-- in the next few days. I plan to have, in this package, things like:
- dh_haskell to automate putting the appropriate package
register/unregister calls in postinst and prerm,
Shouldn't cabal do that for you?
I don't think so.
First, you'd have to use Perl. (Yes, I know, icky language.) You probably don't want to make Cabal a dual-language package. The debhelper lib is Perl-only, and you need to use it to find out things such as exactly what packages are being built, and to actually put the stuff in the scripts at the right place.
Secondly, this represents a very tight coupling with the Debian build system -- probably more than is appropriate for a non-Debian-specific tool. I think the Debian build scripts should be calling Cabal to do things, not the other way around.
plus getting the deps exactly right
Which deps?
From libs to compilers. (There are no manual deps for Haskell binary packages that are not libraries; build-deps only.)
The compiler ones want information from the compiler packages to be done properly, and this isn't going to happen until either the latest ghc6 gets built on sparc and goes into testing or I get bored and upload a new version anyway. I'll probably add the scripts to put
But we can already see what is on the build system and generate a substvars file for it. So in my control file for, say, libghc6-missingh-dev, I can say:
Depends: ${ghc6:Depends}
And it could expand to:
Depends: ghc6 (>= 6.2.1), ghc6 (<< 6.2.2)
Just by seeing that I have 6.2.1-5 installed on my system. Once the compilers provide the appropriate file, it can use it.
You have to modify control somehow. Why not make it easy?
Also, I think you would need to check with the debhelper people before adding dh_* packages/binaries.
Nope, debhelper is modular. All dh_* bins are in /usr/bin. It's no problem to add a new one, and it doesn't mess up debhelper at all.
Scripts for postinst/postrm live in /usr/share/debhelper/autoscripts, and again a haskell-devscripts can just add files there.
- cabal-buildhelper to automate building libraries for up to the
four supported Haskell environments in Debian
I'm not sure how much of this the cabal guys have done. Isaac, Marvin?
From the code I've seen, none.
The basic pseudo code is:
foreach TARGET in ghc5 ghc6 nhc hugs: ./setup clean ./setup configure --with-hc-compiler=$TARGET --prefix=foo ./setup build ./setup install --instprefix=foo cp .*config* wherever configure ghc-pkg/whatever in postinst/prerm
Of course, Cabal doesn't yet actually work with nhc/hmake or ghc5 (haven't tested hugs) so we can't do much just yet.
But here's what I'm planning:
A tool can learn from debhelper (which in turn learns from control) exactly what packages are being built. From that, it can infer what targets need to be built. It can do the cabalized build for each target automatically, installing each at the appropriate spot.
During the binary-arch target in debian/rules, another tool can set up the appropriate postinst/prerm scripts automatically. It can learn from Cabal the package name and thus infer where it's installed and the location of the appropriate pkg file.
Essentially we will have the building of all possible compiler packages for a given library down to three commands in debian/rules and one clause per package in debian/control, with almost everything else handled automatically.
*That's* what I'm waiting for before making dh_make templates. What we have now is fragile and manual. When someone dh_make's a Haskell library, all he has to do is fill in the package name, description, and copyright, and everything else should Just Work for all 4 supported environments.
-- John