What I would like to do is to stabalize an interface one of these days. The problem is that, IMO, we need experience with what users want & need in order to stabalize the interface. When writing layered tools like cabal-get, Lemmih had to modify cabal's interface, and when writing cabal-install, I had to modify the interface.
But I'll definitely look at the Eternal Compatibility thing!
That's good to hear. I think it is a good fit for this situation.
import Data.Version import Control.Exception import System.Cmd import System.IO import System.Exit import System.Directory import Distribution.Setup import Distribution.Simple import Distribution.Simple.Utils import Distribution.Simple.LocalBuildInfo import Distribution.PackageDescription
It would be nice if you used qualified imports so I could see exactly what it is that you need from cabal. Also you'll get better error messages if things disappear.
I'm not sure what you mean here. Do you mean with explicit import lists? Qualified means something very specific in this context and I don't see how it would help.
perlRE = "s/^#\\s+(\\d+)\\s+(\\\"[^\\\"]*\\\")/{-# LINE \\1 \\2 #-}/g;s/\\$$(Id:.*)\\$$/\\1/g"
rawSystem "perl" ["-pi.hspp","-e",perlRE,file]
aaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhh!!!!!!!!!
/me runs away ;)
Just so you don't think I'm responsable for that perl RE mess, its taken directly from the Makefile ;) Yeah, expecting perl on the path is a little ugly but *shrug* its a pretty safe assumption (also made in the Makefile BTW).
But seriously folks, you should check out the new (experimental!) "Program" interface in the CVS / darcs HEAD. The nice thing about it is you can add perl as a Program and configure will find it, and users can say: ./setup configure --with-perl=/my/special/perl.
That sounds nice; I'll have to take a look. Rob Dockins