On Tue, 2006-11-28 at 18:28 +0000, Ross Paterson wrote:
On Tue, Nov 28, 2006 at 12:28:56AM +0000, Duncan Coutts wrote:
It's not clear to me that we need to have an extra field. I had originally envisaged that cabal-setup would just find the right compiler to build Setup.(l)hs and if there was none that it'd use defaultMain (possibly without needing to compile any setup binary).
If there was a Setup.[l]hs, it wouldn't be correct to use defaultMain, would it?
Indeed, it would not. If there's a Setup.[l]hs then we use that. If there isn't then we use Distribution.Simple.defaultMain (either directly or indirectly via a simple Setup.hs).
So do we really need a 'build-type:' field? Arn't there just two values for it, 'Simple' and 'Custom' (since all others are just different implementations of 'Custom')?
In that sense, there's only one value (Custom), but defaultMain is common, and a reasonable number of packages use
main = defaultMainWithHooks defaultUserHooks
which (bizarrely) is not the same as defaultMainWithHooks defaultUserHooks, though it really should be.
I had a value for Distribution.Make.defaultMain too (but I don't know if anyone uses that).
Can't the Simple/Custom distinction be simply if the Setup.(l)hs is present or not?
If you have a field, cabal-setup can avoid compiling Setup.[l]hs in the common cases.
Oh you mean that since people would want to be backwards compatible that they would include a simple Setup.hs and then we loose the advantage of not having to compile Setup.hs and thus having an extra field to say to use simple even if there is a Setup.hs present is a benefit? Yes, it is a benefit but it seems rather marginal to me. Remember that we can't always avoid building a trivial Setup.hs anyway, since in the case that cabal-setup was built with Cabal-x.y and the .cabal requests cabal version x.y+1 then cabal-setup needs to build Setup.hs with the later version of the Cabal lib and use that. Duncan