re: Cabal interface changes proposal
Hi all, I like the idea of adding a layer on top of the current cabal to add "shipments"... this would solve the problem of packages like gtk2hs and wxhaskell mentioned by Duncan Coutts, and allows us to keep the core cabal simple. Since it won't affect the core interface, I'll just push that on the stack and worry about it later. Krasimir suggested that a single cabal package should only have one executable, but I don't agree. I can see the reasons for keeping a one-to-one correspondence between a cabal package and a Haskell package, but I actually really like the way cabal treats executables right now. It's much simpler than libraries since it doesn't require a registration step or anything. It just needs to know where to find main and what to call the binary. As Duncan and Simon pointed out, multiple libraries is actually a more complicated story. So I would say that for now, let's keep the basic structure the same, a single library and multiple executables are allowed in a cabal package file, and hopefully we'll find time to implement "shipments" later so we can bundle together several libraries. I hope that won't hurt anyone too badly in the short term. I'll go ahead and perform the other changes mentioned. Sound OK? peace, isaac
--- isaac jones
Krasimir suggested that a single cabal package should only have one executable, but I don't agree. I can see the reasons for keeping a one-to-one correspondence between a cabal package and a Haskell package, but I actually really like the way cabal treats executables right now. It's much simpler than libraries since it doesn't require a registration step or anything. It just needs to know where to find main and what to call the binary. As Duncan and Simon pointed out, multiple libraries is actually a more complicated story.
I agree that it is completely safe to keep the basic structure the same. My proposal just makes the things even simpler. I would like to know a litle bit more about your plans about executable tools. Lets imagine that there is a library and a preprocesor which are bundled in single package. A good example is the HDirect package which contains the Com library and the ihc tool. ihc translates *.idl files to Haskell modules. Is it possible to add an additional information to the ihc's stanza in the Setup.description that describes the executable as a tool? In the install phase this information can be recorded in a simple database and after that Cabal will know that to compile the .idl file it must use ihc tool. If this is the chosen route then you need to register the executables as well. If in the package there are multiple executables and some of them requires any tool that is in the same package then you will have dependencies between executables as well as between libraries. Cheers, Krasimir __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
On Fri, 2004-11-26 at 02:06 -0800, Krasimir Angelov wrote:
I agree that it is completely safe to keep the basic structure the same. My proposal just makes the things even simpler. I would like to know a litle bit more about your plans about executable tools. Lets imagine that there is a library and a preprocesor which are bundled in single package.
That reminds me of the other complicating factor of the gtk2hs build system. We use 3 bundled source code generators/preprocessors which need to be built to build the other library packages but theses build tools do not get installed. I'm quite happy with leaving the shipments layer until later. Tackle the low hanging fruit first. As a shipment (a collection of inter-dependent packages) gtk2hs is not too hard to describe. It has 5 library packages (some of which may not be built) and 3 executable packages (though the executables are not installed). Duncan
participants (3)
-
Duncan Coutts -
isaac jones -
Krasimir Angelov