Build-depends usefull for Cabal?
Hello Would having a build-depends in addition to depends make sense in Cabal? Most package systems make this distinction. 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. - Einar Karttunen
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
Duncan Coutts
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.
This is my view as well.
There is a slight danger here of duplicating too much on the job of a distro package manager.
I tend to agree. I think other things are higher priority than supporting this, which will end up being much magic. The highest leverage stuff for Cabal right now is Haskell libraries and automatic installation. OTOH, there's a "Program" abstraction that does a pretty good job of locating programs in PATH and stuff. You could build on top of this in the Setup script to detect stuff; there's a hook for it too. Maybe we could even add more library helper functions, and maybe eventually something in the .cabal file. We don't even have all of the preprocessors and libraries properly using the Program abstraction, though. peace, isaac
participants (3)
-
Duncan Coutts -
Einar Karttunen -
Isaac Jones