Why is there a cabal file at all?

Marc Weber marco-oweber at gmx.de
Mon Mar 12 07:53:23 EDT 2007


On Mon, Mar 12, 2007 at 05:43:00AM +0000, Ashish Hanwadikar wrote:
> Marc Weber <marco-oweber <at> gmx.de> writes:
> > 	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
> > Marc
> > 
> 
> I like your idea. I had thought about something similar. See this post 
> (http://ashish.typepad.com/ashishs_niti/2007/03/learning_haskel.html).
> 
> I have put up a Haskell project for Google Summer of Code 2007. I would love to 
> work on this or related idea.

Hi Ashish Hanwadikar!

Have also a look at this project (Duncan has pointed me to it in a previous
post (" debugging support - multidimensional package selection ... ") on this
list).. I hadn't had enough to time to learn it thoroughly but it looks really
promising. Its task is not to build a haskell application, but to manage
dependencies and ensure that they are installed by their own installers (make,
scons, whatsover) a little bit like the portage system of gentoo but it seems
to be much faster. You can also have installed arbitrary amounts of the same
application differing only in the version..

quote Duncan:

" For some related work you might want to look at Nix:
http://www.cs.uu.nl/~eelco/pubs/ "

I have put some effort into my approach and my project can build ghc
executables now, read options from config files. The main advantage over cabal
is this general concept of a package:

data Package = Package { metaInfo :: MetaInfo
		       , actions :: Actions
		       }


type Actions = [(String, Action)]

data Action = Action {  -- on which actions does this action depend? 
		       actionDependencies :: [ String ]
		     , buildDependencies :: CheckedDeps
		     , runDependencies :: CheckedDeps
		     , checkRerun :: CheckRerun 
		     , actionToRun :: ExecutionMonad ActionResult
		     }

Especially for haskell the actions look like this:

             Pkg (HPS.Lang.Haskell.metaInfo hac) $ [  -- these actions will be availible
		   ( "listSourceFiles", empty { 
			   actionToRun = let list = showModules ms
					 in do liftIO $ putStrLn list
					       return $ ActionResult list
			   } ) -- this is needed by IDEs ?
		 , ( "compile", empty { 
			   actionToRun = compile'
			   } )
		 , ( "install", empty {
			   actionToRun = install'
			 , actionDependencies = ["compile"]

			 } )
		     -- , haddock to be implemented
		     -- , bindist -- binary distribution
		     -- , dist -- disribution of source files (in general only preprocessed files are included here ?)
		     -- , clean
		     ]


Note that the action "install" depends on "compile"
and compile will depend on "preprocess" which in turn will depend on "get
sources" or something similar.
A big advantage is that you can add new acitons running configure/make, building preprocessors, running/ building test applications etc. Of course this all is possible using cabal, too. But you have to use hooks which might give you some troubles if you want to build your package in a non standard way (eg wxhaskell, ghc itself? (multistage build), hdirect (two stage build if you need com support on windows))

Drawaback: Needs recent ghc version, a modified DrIft Preprocessor and HList.
I didn't konw how to put definitions in different modules because of mutable recursive dependecies.
Do pretty much seems to be in one file ;)

The 'dependency' analysis of those actions is done in one line:
      (concatMap (reverse . concat . levels) . dfs (graph ag)) idxs

which takes the build graph and finds all dependencies ;)

I've stopped working on it because I think nix does solve many issues I want to
have in a much better way such as installing arbitrary software packages. But I
need to learn more about it before I do know how to proceed.

So at the moment I think I need another build tool but no longer another
cross-platform packaging tool.

I'd like to share my work but I'm not sure wether its worth sharing

Marc


More information about the cabal-devel mailing list