[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
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
More information about the cabal-devel
mailing list