8

What is the recommended procedure for profiling under GHC 7.10.1 and cabal 1.23? The profiling-related error and warning messages from GHC and cabal-install are very inconsistent.

  1. Try to run an executable with profiling, and you are told:

    $ prediction-interactive +RTS -p

prediction-interactive: the flag -p requires the program to be built with -prof

  2. Put -prof in your cabal file, and you are told:

    $ cabal build

Warning: 'ghc-options: -prof' is not necessary and will lead to problems when
used on a library. Use the configure flag --enable-library-profiling and/or
--enable-executable-profiling.

  3. Follow that advice (and remove -prof from the cabal file), and you are told:

    $ cabal configure --enable-executable-profiling

Resolving dependencies...
Configuring creatur-wains-prediction-1.0...
Warning: The flag --enable-executable-profiling is deprecated. Please use
--enable-profiling instead.

  4. Follow that advice, and you are told:

    $ cabal configure --enable-profiling

Resolving dependencies...
Configuring creatur-wains-prediction-1.0...

$ cabal build

. . .
Installing executable(s) in
/home/eamybut/nosync/sandboxes/prediction-wains/bin
Installed creatur-wains-prediction-1.0

$ prediction-interactive +RTS -p

prediction-interactive: the flag -p requires the program to be built with -prof

Facepalm!

EDIT: Added cabal build in step 4.

Bakuriu
  • 98,325
  • 22
  • 197
  • 231
mhwombat
  • 8,026
  • 28
  • 53
  • And if you run `cabal build` now? – Reid Barton Jun 10 '15 at 14:23
  • @ReidBarton, I did do a second cabal build (just forgot to mention it), and it ran without errors. I've updated the question. – mhwombat Jun 10 '15 at 14:41
  • Are you sure you're running the executable that was just built, rather than one that was installed to your PATH earlier? (You can use `cabal run -- +RTS -p` to run the executable that cabal has just built, or invoke it via its path `dist/...`.) – Reid Barton Jun 10 '15 at 14:59
  • @ReidBarton Now *that's* interesting... Although I omitted it above, I was actually running the executable by pointing to the binary in the `bin` directory in the sandbox. That binary has the timestamp of the last time I changed anything and did `cabal build`. But now when I run it using `cabal run -- +RTS -p`, it creates a new executable, which does work, and I get profiling info as expected. Maybe `cabal build` doesn't produce a new executable unless there's been a change in *source* code (as opposed to a change to the cabal file)? I'll have to experiment. – mhwombat Jun 10 '15 at 15:26
  • 3
    I don't use sandboxes much but I wouldn't expect `cabal build` to ever install anything into the sandbox. So that part has me a bit confused. I expect `cabal build` to build an executable to `dist/build/foo/foo` and for `cabal run` to run that executable. – Reid Barton Jun 10 '15 at 16:08
  • @ReidBarton Now that you say it, that makes sense. But I'd always thought of the `dist` directory as being full of stuff I don't need to see. In my mind `dist` had nothing to do with sandboxes, since sandboxes didn't exist in the beginning. With non-sandboxed builds, any executable produced goes into your `.cabal/bin`. So then when sandboxes became a thing, there was this new directory (the sandbox), and I expected the executable to go there. – mhwombat Jun 10 '15 at 16:55
  • Right, but the executables only go to `.cabal/bin` on `cabal install`, not `cabal build`. And `cabal install` with a sandbox installs the executable into the sandbox, so I wouldn't expect `cabal build` to touch the sandbox at all. – Reid Barton Jun 10 '15 at 17:03
  • Ah, that makes perfect sense. Thank you. – mhwombat Jun 10 '15 at 17:12
  • @ReidBarton as you seemed to answer the question with your comment, perhaps you can post it as an answer? – sclv Mar 08 '16 at 04:40

0 Answers0