On Fri, 2006-08-04 at 03:20 +0300, Einar Karttunen wrote: > Hello > > Would having a build-depends in addition to depends make sense in > Cabal? Most package systems make this distinction.
Yes, for example in Gentoo ebuilds there is a DEPEND and RDEPEND field for build time and runtime deps. They are usually mostly overlapping so ebuild semantics say that if left unspecified one defaults to the other. > I can think of two use cases for this: > > 1) TH libraries (if GHC starts supporting avoiding to link to them) > > * I am packaging a library of TH utility functions for > class deriving. Most programs need this only on build > time and don't need it at runtime (except for GHC linker reasons). > > 2) It would make tool dependencies clearer > > * It is currently impossible to depend upon a tool at runtime. > But is this needed for Cabal? > > 3) It would make translating dependencies to other package systems > easier. > > > This is not high priority at any rate. The build-depends field would > default on the value of depends. How about tools that are needed only at build time? I know that a hypothetical Cabalised Gtk2Hs would like to express a versioned build-time dep on c2hs. For built or run time deps on tools do you suggest only deps on cabal-installed binaries or general external tools? We do not yet have any particular support for specifying external/foreign deps eg on C libs. Another reason is that we do not have any standard way of detecting cabal-installed programs like we do with libs so detecting tools is more ad-hoc than libs. There is a slight danger here of duplicating too much on the job of a distro package manager. Duncan _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel