On Mon, 2009-01-26 at 13:40 +0000, Eric Kow wrote: > On Mon, Jan 26, 2009 at 11:02:01 +0000, Duncan Coutts wrote: > > > > Am I correct in thinking that supporting Cabal 1.4 is non-trivial and > > > > not worth the effort? > > > > > > Care to comment, Duncan? > > > > It depends what you're doing. I didn't get any of the context. Certainly > > cabal version-specific code in Setup.hs is problematic. > > The context is that we're switching to Cabal as the default build method > for darcs. > > The Cabal file and Setup.lhs you have written us has an explicit > dependency on 1.6 and we were wondering if there was a particularly > strong reason to do this, and if it would be extremely inconvenient to > make it work with Cabal 1.2.
I think it's possible. I'll let you make the judgement about convenience. See below. > (I now say 1.2 instead of 1.4, because it's what ships with GHC 6.8, > which is presumably what Trent is after...). > > I think we're OK with requiring Cabal 1.6. It's just that if we can > easily get away without it, we might as well try to minimise the pain on > our users. So there's two things to look at, features in the .cabal file and the API used in the Setup.hs. If I change the cabal-version field to >= 1.2 then I get these distribution errors: The package uses wildcard syntax in the 'build-depends' field: mtl ==1.1.*, ... To use this new syntax the package need to specify at least 'cabal-version: >= 1.6'. Alternatively, if broader compatability is important then use: mtl >=1.1 && <1.2, ... Using wildcards like 'src/*.h', 'tools/cgi/xslt/*.xslt', 'tools/cgi/xslt/*.xml' in the 'extra-source-files' field requires 'cabal-version: >= 1.6'. Alternatively if you require compatability with earlier Cabal versions then list all the files explicitly. The 'source-repository' section is new in Cabal-1.6. Unfortunately it messes up the parser in earlier Cabal versions so you need to specify 'cabal-version: >= 1.6'. Unfortunately the language extensions 'MagicHash', 'DeriveDataTypeable', 'GADTs', 'TypeOperators', 'KindSignatures' break the parser in earlier Cabal versions so you need to specify 'cabal-version: >= 1.2.3'. Alternatively if you require compatability with earlier Cabal versions then you may be able to use an equivalent compiler-specific flag. You can follow the advice to get a more verbose .cabal file that would be compatible with Cabal-1.2.3 which is what came with ghc-6.8.2. If you require compatibility with the version of Cabal-1.2.1 which came with ghc-6.8.1 then you'd also have to not list those language extensions. As for the Setup.lhs, try building it with Cabal-1.2.3.0. You can switch display and autogenModulesDir for local versions. You will have to stop using "x-" custom fields. That's easy for all the cases except x-have-libwww but you could use cpp options as a marker instead. The only reason the "x-have-blah" stuff is done the way it is currently is for compatability with the Autoconf.lhs that was used by configure and franchise. ccLdOptionsBuildInfo could be reimplemented locally. Verbosity could be hard coded. withFileContents and rewriteFile could either be reimplemented locally or alternatives used instead, though the behaviour of rewriteFile is handy to stop rebuilds. There are alternatives to packageVersion, use the underlying function rather than the class one. Duncan _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
