New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wereHamster opened this Issue Oct 16, 2015 · 9 comments

Comments

Projects
None yet
5 participants
@wereHamster

wereHamster commented Oct 16, 2015

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

This comment has been minimized.

Contributor

borsboom commented Oct 26, 2015

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

@wereHamster

This comment has been minimized.

wereHamster commented Oct 26, 2015

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

This comment has been minimized.

Contributor

borsboom commented Nov 1, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Nov 1, 2015

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

This comment has been minimized.

Contributor

borsboom commented Nov 1, 2015

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.

@borsboom borsboom added the type: bug label Nov 1, 2015

@borsboom borsboom added this to the P2: Should milestone Nov 1, 2015

@borsboom borsboom changed the title from Can't build snap dependency when profiling is enabled to Never build snapshot dependencies with executable profiling enabled (was: Can't build snap dependency when profiling is enabled) Nov 1, 2015

@MichaelXavier

This comment has been minimized.

MichaelXavier commented Mar 11, 2016

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

This comment has been minimized.

Collaborator

mgsloan commented Mar 15, 2016

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

Literally as easy as adding && isLocal, XD

@MichaelXavier

This comment has been minimized.

MichaelXavier commented Mar 15, 2016

@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

This comment has been minimized.

Collaborator

mgsloan commented Mar 16, 2016

Great, glad it worked!

@mgsloan mgsloan closed this Mar 16, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment