-O in 6.8.1-candidate

[Duncan Coutts]

On Sat, 2007-10-20 at 21:11 +0400, Serge D. Mechveliani wrote:
> On Sat, Oct 20, 2007 at 03:25:04PM +0100, Duncan Coutts wrote:
> > On Fri, 2007-10-19 at 10:54 -0300, Isaac Dupree wrote:
> > 
> > > How can user who does not modify Cabal file choose between all three of 
> > > -O0, -O and -O2? 
> > 
> > They cannot. Cabal currently only support a binary notion of
> > optimisations. So it's either -O0 or -O.
> > 
> 
> As I understand, the Cabal developers claim that a user of an applied 
> package  p  does not need to change anything in the file  p.cabal.

That is the aim, yes.

> But there is a contradition here. 
> For example, a user may need to build  p  via  p.cabal  under GHC and 
> once under -Onot and next time under -O2.  Suppose also that once the 
> user needs to build  p  under  -prof -auto-all  and next time -- under
> -prof  only. How can one do all this without intruding into  p.cabal ?

We don't claim that every possible ghc feature is exposed conveniently
via Cabal. (If it were, there would be no point to having Cabal at all)

So Cabal provides a way for users to choose between optimising or not,
and building for profiling or not. The distinction between -O and -O2,
and the distinction between -prof and -prof -auto-all is not something
that Cabal exposes in a Haskell-implementation-independent way.

If this is something that is vital for your users then there is the more
general (but less convenient) Cabal configurations system. You can have
flags which can be set by the user and you can define how the affect how
your package is built. For example:

flag optimise-more
  description: ...

library
  ...
  if flag(optimise-more)
    ghc-options: -O2
    jhc-options: ...

Then you would tell your users to use an extra flag at configuration
time:

runghc Setup.hs configure -f optimise-more 

> Personally, I would like better if the default for Cabal does not set 
> any GHC options, and a user to be invited to edit the field   
> `ghc-options:' in the .cabal file.  This way, it looks simpler and 
> less confusive.

The problem with that is that it does not help make their packages
portable between different Haskell implementations and it requires that
all users know what the short cryptic ghc command line options mean.
Editing a .cabal file is also something that does not make packaging
convenient. For example how is a user of a rpm package, or someone using
cabal-install supposed to specify these configuration options if they
have to edit the .cabal file by hand?

Duncan