Remove Setup.hs, use Setup.lhs only

Isaac Jones ijones at
Sun Nov 26 18:27:31 EST 2006

Ian Lynagh <igloo at> writes:

> On Sat, Nov 25, 2006 at 09:57:50AM -0800, Isaac Jones wrote:
>> Ross Paterson <ross at> writes:
>> > On Wed, Nov 22, 2006 at 01:36:13AM +0000, Duncan Coutts wrote:
>> >> Note that in future we intend to allow there being no Setup.(l)hs at all
>> >> when using cabal-setup. No Setup.(l)hs file would be equivalent to the
>> >> basic one that uses defaultMain.
>> >
>> > Could we have an optional field in the package description to tell
>> > cabal-setup which setup to use?  There could be tokens representing
>> >
>> > 	main = Distribution.Simple.defaultMain
>> > 	main = Distribution.Simple.defaultMainWithHooks defaultUserHooks
>> > 	main = Distribution.Make.defaultMain
>> Since we've decided to go with making Setup.[l]hs optional, I agree
> What's the advantage of making it optional, especially now we have
> mkcabal to make the defaultMain Setup.lhs for us? It would be much
> simpler, IMO, if it was the case that all cabal packages have a
> Setup.lhs file.
> As we need to support the presence of a Setup.lhs, no tool can be made
> simpler by allowing it to be absent (and many will need a little extra
> complexity to cope), and the only saving is a tiny amount of compilation
> for one (admittedly common) case.

I see your point about layered tools needing to do a somewhat more
complex check for Setup.lhs.  Really, layered tools should try to use
cabal-setup and let that tool handle finding the Setup file (or not)
but cabal-setup isn't in common use yet.

But if we're talking about tools in Debian and Gentoo, it would
probably be best to require that cabal-setup is there and just use

The thing about requiring Setup.lhs is that it makes running setup
just a little more complex than it needs to be; runhaskell isn't
really in common use yet and compiling Setup files still can cause

I still think that if Haskell were as easy to envoke as something like
perl or php (via runhaskell), we'd have more adoption.  I know it
doesn't help that Cabal's API isn't particularly stable.



More information about the cabal-devel mailing list