-O in 6.8.1-candidate

[Isaac Dupree]

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