-O in 6.8.1-candidate

[Duncan Coutts]

On Sat, 2007-10-20 at 11:13 -0400, Isaac Dupree wrote:
> Duncan Coutts wrote:
> >
> > 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.

Right, we have "ghc-options:" in the .cabal file for developers and
cabal-setup configure --ghc-options= for users/packagers/distributors.

> >> 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

Yes, cabal-setup configure --help lists all the programs that the flags
--with-$PROG= and --$PROG-option(s)= apply to. The set of programs is
not fixed as it can be extended by the Setup.hs file.

I'm not sure if this is well documented in the user guide. Documentation
patches are always gladly accepted.

> > 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?

Right.

> after all why make a divide between users and devs?)

Because they have different intentions and levels of knowledge about the
tools.

> >> 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.

Perhaps this could be integrated into the new introduction I posted for
review the other day:

http://haskell.org/pipermail/glasgow-haskell-bugs/2007-October/010388.html

> 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?

You mean what flags are commonly used in compiler-specific options
fields that are not currently covered by generic Cabal features like
--enable-optimzation etc?

The most common ones I see probably are -Wall and other specific warning
flags, -O2. Some packages specify things like "ghc-options: -DFOO=BAR"
but that's now covered by the portable "cpp-options:" field. Some use
"ghc-options: -fglasgow-exts" because they only use extensions when
they're using ghc and otherwise use portable code. This could be
replaced with the clearer:

if impl(ghc)
  extensions: Blah

As I said, I'm not sure about -auto-all. I've not seen any packages use
that before, except docon.

Duncan