Why is there a cabal file at all?

10 Jan 2007

      Sorry for this stupid question put there must be reasons I don't know.

I've been thinking a lot about packaging/ dependency handling etc the
last days.

Haskell is one of the most typesafe and expressive languages, right?

Now we need a haskell compiler/ interpreter to run Setup.hs.

So why not combine both and use some kind of cabal combinator library?

I'll try to implement a prototype although knowing there are lots of
people knowing how to do this better.

module Setup where
import CabalBuildProposal

helloWorld = haskell-executable $ do
  setName "helloworld"
  sourceDir "src" $ mainIs "HelloWorld.hs"
  addDependencies = case stringOption "pretty_print_lib" of
    "A" : [LibVersionRange "A" "1.0 - 2.0"]
    "B" : [LibVersionRange "B" "1.0 - 2.0"]

package = do
  setAuthor = "Marc Weber"
  addAtom helloWorld

preprocess = defaultHaskellPreprocess
build = preprocess >>= defaultHaskellBuild
rpm = build >>= defaultRPM
install = defaultHaskellInstall
haddock = defaultHaddock

targets = [ ("preprocessOnly", preprocess)
	  , ("build", build )
	  , ("install", build >>= install) 
	  , ("rpm", rpm ) 
	  , ("haddock", preprocess >>= haddock)
	  ]

main = do
  handle package targets

using preprocessors might be done in this way:

addExposedModules $ map preprocessByCPP $ modulesByRegex "src/**/*.hs"

I think you get the idea why this approach might be much more powerful?
The package mantainers of ght2hs and wkhaskell have both trouble makeing their
project work with cabal..
So why do we limit ourself using cabal files like the existing ones?

I think you've noticed the line 
	addDependencies = case stringOption "pretty_print_lib" of

This should use the correct dependency if the option has already been set by
cmdline or config file else ask the user or choose the first but noticing the
user by printing a message like this:

	unset option "pretty_print_lib", defaulting to "A"

preprocess should be passed all configuration options and return a list of source files,
build should get the list of source file and return a list of executables
which are installed by install

straightforward, isn't it?

Thus the right build/ install whatsoever step would be choosen not by defining
hooks but by the haskell type system.
This way the packaging system user can plug in his own implementation
everywhere.

Any ideas, comments?

Anyone out there who wants to join and help implementing this idea?

Marc