Remove Setup.hs, use Setup.lhs only

Isaac Jones ijones at
Mon Nov 27 18:06:01 EST 2006

Ross Paterson <ross at> writes:

> On Sat, Nov 25, 2006 at 09:57:50AM -0800, Isaac Jones wrote:
>> So a summary of the new rules would be something like:
>> * Setup.lhs will be found automatically, as it is now.
>> * Setup.hs will be found and complained about with an error.  Maybe in
>>   the interim, we can have a warning.  In the common case, the error
>>   can be fixed by deleting Setup.hs and using cabal-setup :)
>> * Setup will become optional, and cabal-setup will do the job of
>>   defaultMain (or whatever is in the new field).
>> * A new field will be introduced to indicate what kind of build system
>>   cabal-setup should use, in the absense of a Setup.lhs file.
> I'd suggest putting the last two slightly differently.  As I understood
> it, the idea of cabal-setup is that you have it pre-compiled on your
> system, and you always run it, because it's smart enough to find a
> compiler and suitable Cabal version to execute Setup.lhs.


> If this field is set to something other than Custom, cabal-setup can
> ignore Setup.lhs, and just do the appropriate thing itself (making
> Setup.lhs optional).

That's a good idea.  People can include Setup.lhs to be backward
compatible, but if the Build-Type field is Custom (for instance) we
can ignore it.

I guess if they say "Custom" then we look for Setup.lhs only, (and
maybe Setup.hs to give a helpful hint).  I think I mentioned the idea
of letting them give an arbitrary path, but that just seems like a bad

> For backward compatibility, you'd probably want the default value of
> the new field to be Custom, though this would mean you couldn't omit
> Setup.lhs unless this field was set.


>> Ross, how do you see the fields panning out?  Want to implement it? :)
> Something like
> 	Build-Type: (Simple|Configure|Make|Custom)
> I'd be happy to implement it, if/when we get agreement.

Cool.  What do others think of all this?



More information about the cabal-devel mailing list