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
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
