On Thu, 2007-10-18 at 11:02 +0400, Serge D. Mechveliani wrote: > On Oct 17, 2007, Don Stewart and Duncan Coutts wrote: > > > > [..] > > > By default cabal uses ghc -O to build projects, so you won't see any > > > difference if you comment it out of the cabal file. You will however > > > if you explicitly turn off optimisations: > > > > > > ghc-options: -Onot > > > > or: > > > > cabal-setup configure --disable-optimization > > > > since the default is --enable-optimization which with ghc uses -O
> For GHC, it is necessary for the .cabal file to provide the field > `ghc-options:', > and the optimization keys are of this field. > Hence, is not this confusing to allow the optimization keys anywhere > else? > Also seeing `--enable-optimization' the user needs also to recall of what > kind of optimization is it. The ghc-options field allows you to pass anything flags you like to ghc. That does not mean that you should! :-) Cabal is supposed to be portable between Haskell implementations and to allow packages to also be portable. Some Haskell implementations provide a notion of optimisation and so Cabal supports that with the --enable-optimization flag. There's an additional advantage here, we can let the user decide if they want to build with or without optimization. With the ghc-options field, only the developer gets to decide. So, in summary it's much better not* to use lines like: ghc-options: -O and to let the user manage that with Cabal's --enable-optimization flag (which is on by default). If you have specific ghc optimisations that you really need to be applied, then it's ok to use the ghc-options: field. For example we use that in bytestring. The --enable-optimization flag also applies to other things, like compiling C code and in principle could apply to other tools like happy/alex, though at the moment it does not. Duncan _______________________________________________ Glasgow-haskell-bugs mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
