#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 Comment: 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-1.6.0.2 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