On Fri, Oct 19, 2007 at 01:25:27AM +0100, Duncan Coutts wrote: > 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 >
Currently, my DoCon application has the file docon.cabal, with the field ghc-options: <many options> ... -O +RTS -M400m -RTS -- -prof -- -auto-all This file defines how to build the DoCon library. And a DoCon user is invited to comment-out or un-comment, or change any of the last 4 lines in this field definition. By this, the user defines, for example, whether to compile the library with -O, with -O2, or with -Onot. The meaning of these options is explained in the GHC documentation. If it also aimed to build under, say, HBC tool, then, I would probably need to add the field hbc-options: ... and set there the keys according their meaning explained in the HBC documentation. This was my idea. I do not know ... Regards, ----------------- Serge Mechveliani [EMAIL PROTECTED] _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs