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.
(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.
No, none of the above is true (or I miscommunicated) : they are
supported in the following way of --programname-option. User is not
supposed to (need to) modify .cabal file, nor be restricted to only
issue commands that make sense on all implementations.
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)=
I suppose cabal documents what programs it may use somewhere
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
That's interesting. It probably supercedes specific README instructions
"modify the cabal file in this or that particular way". (and user poking
around can always still use --ghc-option or equivalently modify the
.cabal file? after all why make a divide between users and devs?)
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?
check this for accuracy and appropriateness:
Most of the time compiler-specific behavior isn't needed. Language
extensions are specified with "extensions:". When a package always
should have a specific compiler flag with a specific compiler (for
example, ---give a good example flag here---), this should go in fields
like "ghc-options:" in the .cabal file. If the user of a package wants
to customize how it's built with a particular compiler, they can use
cabal's `configure --ghc-option=-Wall --ghc-option=-Werror`. If there
is a particularly common customization such that the package developer
wants to support an easy choice by the users, see the configurations
flag system section.
What flags are known to be used compiler-specific? Each appropriateness
could be discussed specifically of course.
-O2
-Wall, and other GHC warning-flags
-auto-all
others? what Hugs or other impls' flags are used?
Isaac
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
