Never build snapshot dependencies with executable profiling enabled (was: Can't build snap dependency when profiling is enabled)

[wereHamster]

My app is a pretty straight forward web app based on snap. I need to build it with profiling enabled, but that fails. It works fine when profiling is not enabled.

$ stack build --executable-profiling
snap-0.14.0.6: configure
snap-0.14.0.6: build
Progress: 1/2
--  While building package snap-0.14.0.6 using:
      $HOME/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-osx-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/ build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

[... snip ...]

[34 of 34] Compiling Snap             ( src/Snap.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Snap.p_o )
    In-place registering snap-0.14.0.6...
    Preprocessing executable 'snap' for snap-0.14.0.6...
    [1 of 2] Compiling Snap.StarterTH   ( src/Snap/StarterTH.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/snap/snap-tmp/Snap/StarterTH.p_o )

    src/Snap/StarterTH.hs:37:32: Warning:
        In the use of ‘free’ (imported from System.Directory.Tree):
        Deprecated: "Use record 'dirTree'"

    src/Snap/StarterTH.hs:39:29: Warning:
        In the use of ‘free’ (imported from System.Directory.Tree):
        Deprecated: "Use record 'dirTree'"
    [2 of 2] Compiling Main             ( src/Snap/Starter.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/snap/snap-tmp/Main.p_o )
    src/Snap/Starter.hs:1:1:
        cannot find normal object file ‘.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/snap/snap-tmp/Snap/StarterTH.dyn_o’
        while linking an interpreted expression

Might be related to #608. Though apparently that bug has been fixed a long time ago. I'm using GHC 7.10.2.

I don't really need to profile snap, I know the performance problem is elsewhere. An acceptable workaround for me would be to compile snap normally and everything else with profiling enabled.

[borsboom]

I don't suppose you can give us access to the project? Or provide an example project that demonstrates the problem?

[wereHamster]

git clone git@gist.github.com:ae7d56720d2938d7c3af.git stack-test
cd stack-test
stack build --executable-profiling    

[borsboom]

The cannot find normal object file ‘.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/snap/snap-tmp/Snap/StarterTH.dyn_o’ error doesn't seem to be Stack-specific. I got the same error building snap using cabal install --enable-library-profiling --enable-executable-profiling in a fresh cabal sandbox. So I think that's an upstream issue (looks related to snapframework/snap#112).

Here's a workaround that worked for me:

stack build --library-profiling
stack build --executable-profiling

The first builds the snap library with profiling, but doesn't try to build the snap executable with profiling. The second then builds local packages with executable-profiling, but doesn't bother trying to rebuild snap because the library is already built with profiling.

@snoyberg: I'm thinking that, for the sake of consistency, building snapshot dependencies should ignore --executable-profiling (currently you get different results depending on what you happened to do first). Thoughts?

[snoyberg]

I'm OK with that. I'll admit that I don't have a deep understanding of what
goes on with executable-profiling right now.

On Sun, Nov 1, 2015 at 8:17 AM, Emanuel Borsboom notifications@github.com
wrote:

The cannot find normal object file
‘.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/snap/snap-tmp/Snap/StarterTH.dyn_o’
doesn't seem to be Stack-specific. I got the same error building snap using cabal
install --enable-library-profiling --enable-executable-profiling in a
fresh cabal sandbox. So I think that's an upstream issue (looks related to
snapframework/snap#112 snapframework/snap#112
).

Here's a workaround that worked for me:

stack build --library-profiling
stack build --executable-profiling

The first builds the snap library with profiling, but doesn't try to build
the snap executable with profiling. The second then builds local packages
with executable-profiling, but doesn't bother trying to rebuild snap
because the library is already built with profiling.

@snoyberg https://github.com/snoyberg: I'm thinking that, for the sake
of consistency, building snapshot dependencies should ignore
--executable-profiling (currently you get different results depending on
what you happened to do first). Thoughts?

—
Reply to this email directly or view it on GitHub
#1179 (comment)
.

[borsboom]

I think in this case it's something related to the Template Haskell in used to build the executable . With cabal-install, doing cabal install --enable-library-profiling followed by cabal install --enable-library-profiling --enable-executable-profiling works, but I don't know why.

[MichaelXavier]

I found myself running into this exact same issue. I don't know the possible side effects of having dependencies ignore executable profiling but it would sure be helpful from where I sit. I have 2 dependencies (1 indirect) whose executables I do not use. Because executable profiling applies to the main project and all dependencies, this blocks me from being able to compile my own project's executables with profiling because executables that I don't use fail to compile with that flag.

[mgsloan]

@MichaelXavier I've pushed a commit that should help the issue. Does it?

Literally as easy as adding && isLocal, XD

[MichaelXavier]

@mgsloan by all accounts that seems to have done the trick! Thanks so much for looking into this. I can now ship profiling builds to production for debugging some really tricky issues.

[mgsloan]

Great, glad it worked!