[Hackage] #200: Allow more convenient use of ghc profiling options -auto and -auto-all

Hackage trac at galois.com
Thu Jan 22 11:00:22 EST 2009

#200: Allow more convenient use of ghc profiling options -auto and -auto-all
  Reporter:  guest          |        Owner:                 
      Type:  enhancement    |       Status:  new            
  Priority:  normal         |    Milestone:  Cabal-1.8      
 Component:  Cabal library  |      Version:                 
  Severity:  normal         |   Resolution:                 
  Keywords:                 |   Difficulty:  easy (<4 hours)
Ghcversion:  6.8.2          |     Platform:                 
Changes (by duncan):

  * milestone:  Cabal-1.6 => Cabal-1.8


 Come on, this is easy to implement. All we need is to agree on the user
 interface! What command line options should we use?

 To be concrete, the proposal is:

 For libraries we have:
 cabal configure --enable-library-profiling

 Keeps its current meaning which is to compile this package to allow
 dependent packages to be profiled, but not with the intention of profiling
 this package. For ghc it implies `-prof`.

 cabal configure --enable-library-profiling-this-package-yes-this-one!!!1

 This enables profiling but with the intention of profiling this package.
 For ghc it implies `-prof -auto-all`. This is where we obviously want a
 sensible suggestion for the flag name.

 For executables we have:
 cabal configure --enable-executable-profiling

 Which currently, for ghc, builds the exe just with basic profiling. Unlike
 with libraries, executable have no deps, so generally the only reason to
 build an exe with profiling support is to profile that exe. The suggestion
 is that the default be changed to use `-auto-all` because that is the most
 common method people use.

 However some advanced uses might need to use `-prof` on it's own with
 manually annotated SCCs, or with flags `-auto` or `-caf-all`.

 cabal configure --enable-executable-profiling-but-without-auto-all!!1

 Similarly we need a sensible name for this. People would use this in
 combination with `--ghc-option=-caf-all` if necessary.

 Now it looks like we need different flags to turn on/off the use of
 `-auto-all` for libs vs exes. The default values are different for exes vs
 libs, so having two flags makes things simpler. We could possibly use one
 flag to toggle both settings away from their defaults. It would mean that
 for a package like darcs with both a lib an an exe, that we could not
 build the lib with `-auto-all` but the exe without.

 Having said all that, I'm not sure we can get this into Cabal-
 because it changes the API by changing an exposed type (the type of
 command line settings which is passed to the user hooks). So perhaps we
 have to punt for 1.8. That's probably ok as nobody seems to be shouting
 about this one.

Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/200#comment:9>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

More information about the cabal-devel mailing list