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.
> (Not knowing about profiling,) What if user wants to
> decide whether to use -auto-all? Somehow your answers don't seem to
> answer.
Bear in mind that since Cabal is supposed to be portable it cannot
translate every feature of every compiler. We decided initially that the
notion of optimisation was important enough and supported by enough
Haskell implementations to make sense supporting, but different levels
of optimisation is getting quite compiler-specific.
> (some compilers may have idiosyncratic flags that USERS of THAT
> COMPILER want to choose for their own reasons)
Which is why we have ghc-options, nhc98-options etc in the .cabal files.
> Now, IIRC cabal has something like a --ghc-option= flag that can be
> used in either configure or build, I can never remember which; and, if
> lucky, GHC has a way to override a prior -auto-all flag on the command
> line; "-auto-all" you, as user, may or may not have known was there.
Right and we have a generic mechanism to pass any additional options to
any program that Cabal knows about, like configure --ghc-option(s)=
There is also the configurations system, so if your package needs extra
nobs for a user to play with you can do exactly that:
flag ricer
description: compile with even more optimizations
library
...
if flag(ricer)
ghc-options: -O2 -fgo-really-really-fast -funfolding-threshold=∞
Then all you have to tell the user has to do is:
cabal-setup configure -f ricer
On the issue of profiling with -auto-all I'm less clear about when that
would be wanted. We have it off by default at the moment. Perhaps we can
talk about what the default should be in various situations, and if it
should be something that the user would want to turn on or off or if we
can make a sensible decision automatically.
> This may be okay. The documentation should be clearer about this too,
> if so.
Any specific suggestion? Or even better some text or a patch?
Duncan
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
