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