Skip to content
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

Success return code after there were build errors #365

Closed
lrworth opened this issue Jun 20, 2015 · 13 comments
Closed

Success return code after there were build errors #365

lrworth opened this issue Jun 20, 2015 · 13 comments
Milestone

Comments

@lrworth
Copy link

@lrworth lrworth commented Jun 20, 2015

I have been running this command to build and run my program:

stack build && ./.stack-work/install/x86_64-osx/lts-2.14/7.8.4/bin/test

If the build ever fails, this does the right thing and doesn't run test. However, if I then run the same command right away without modifying any files, stack build returns a success code and then test is run.

I expect stack build to return non-success if the last build failed.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 21, 2015

What's your --version and --verbose output?

@lrworth
Copy link
Author

@lrworth lrworth commented Jun 21, 2015

ravel:test lukeworth$ ./.stack-work/install/x86_64-osx/nightly-2015-06-17/7.10.1/bin/test 
Hello, World!

ravel:test lukeworth$ cat > Main.hs
module Main where
main = ^definitely%some*compile@@err0r`s

ravel:test lukeworth$ ~/stack-0.0.3-x86-64-osx/stack build --verbose && ./.stack-work/install/x86_64-osx/nightly-2015-06-17/7.10.1/bin/test 
2015-06-21 05:48:12.090927: [debug] Checking for project config at: /Users/lukeworth/Documents/Proteus/Source/test/stack.yaml @(stack-0.0.3:Stack.Config src/Stack/Config.hs:522:9)
2015-06-21 05:48:12.092873: [debug] Loading project config file stack.yaml @(stack-0.0.3:Stack.Config src/Stack/Config.hs:543:13)
2015-06-21 05:48:12.112896: [debug] Run process: ghc --info @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:13.169828: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:13.265795: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:13.322057: [debug] Run process: ghc-pkg --no-user-package-db --package-db=/usr/local/Cellar/ghc/7.10.1_1/lib/ghc-7.10.1/package.conf.d/ describe Cabal @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:13.38514: [debug] Checking resolver: nightly-2015-06-17 @(stack-0.0.3:Stack.Build.Source src/Stack/Build/Source.hs:68:13)
2015-06-21 05:48:13.752266: [debug] Run process: ghc-pkg --global --no-user-package-db dump --expand-pkgroot @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:13.827984: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db /Users/lukeworth/.stack/snapshots/x86_64-osx/nightly-2015-06-17/7.10.1/pkgdb/ dump --expand-pkgroot @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:13.891587: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db /Users/lukeworth/Documents/Proteus/Source/test/.stack-work/install/x86_64-osx/nightly-2015-06-17/7.10.1/pkgdb/ dump --expand-pkgroot @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:14.666054: [info] test-0.1.0.0: build @(stack-0.0.3:Stack.Build.Execute src/Stack/Build/Execute.hs:454:18)
2015-06-21 05:48:14.666266: [debug] Run process: /usr/local/bin/runhaskell -package=Cabal-1.22.2.0 -clear-package-db -global-package-db -package-db=/Users/lukeworth/.stack/snapshots/x86_64-osx/nightly-2015-06-17/7.10.1/pkgdb/ /Users/lukeworth/Documents/Proteus/Source/test/Setup.hs --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.2.0/ build @(stack-0.0.3:Stack.Build.Execute src/Stack/Build/Execute.hs:548:13)
2015-06-21 05:48:15.192878: [info] Building test-0.1.0.0... @(stack-0.0.3:Stack.Build.Execute src/Stack/Build/Execute.hs:786:18)
2015-06-21 05:48:15.23082: [info] Preprocessing executable 'test' for test-0.1.0.0... @(stack-0.0.3:Stack.Build.Execute src/Stack/Build/Execute.hs:786:18)
2015-06-21 05:48:15.364103: [info] [1 of 1] Compiling Main             ( Main.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/test/test-tmp/Main.o ) @(stack-0.0.3:Stack.Build.Execute src/Stack/Build/Execute.hs:786:18)

Main.hs:2:8: parse error on input ‘^’

--  While building package test-0.1.0.0 using:
      /usr/local/bin/runhaskell -package=Cabal-1.22.2.0 -clear-package-db -global-package-db -package-db=/Users/lukeworth/.stack/snapshots/x86_64-osx/nightly-2015-06-17/7.10.1/pkgdb/ /Users/lukeworth/Documents/Proteus/Source/test/Setup.hs --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.2.0/ build
    Process exited with code: ExitFailure 1

ravel:test lukeworth$ ~/stack-0.0.3-x86-64-osx/stack build --verbose && ./.stack-work/install/x86_64-osx/nightly-2015-06-17/7.10.1/bin/test 
2015-06-21 05:48:17.950052: [debug] Checking for project config at: /Users/lukeworth/Documents/Proteus/Source/test/stack.yaml @(stack-0.0.3:Stack.Config src/Stack/Config.hs:522:9)
2015-06-21 05:48:17.950551: [debug] Loading project config file stack.yaml @(stack-0.0.3:Stack.Config src/Stack/Config.hs:543:13)
2015-06-21 05:48:17.958895: [debug] Run process: ghc --info @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:18.047131: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:18.089666: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:18.137281: [debug] Run process: ghc-pkg --no-user-package-db --package-db=/usr/local/Cellar/ghc/7.10.1_1/lib/ghc-7.10.1/package.conf.d/ describe Cabal @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:18.20138: [debug] Checking resolver: nightly-2015-06-17 @(stack-0.0.3:Stack.Build.Source src/Stack/Build/Source.hs:68:13)
2015-06-21 05:48:18.564059: [debug] Run process: ghc-pkg --global --no-user-package-db dump --expand-pkgroot @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:18.637123: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db /Users/lukeworth/.stack/snapshots/x86_64-osx/nightly-2015-06-17/7.10.1/pkgdb/ dump --expand-pkgroot @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
2015-06-21 05:48:18.681914: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db /Users/lukeworth/Documents/Proteus/Source/test/.stack-work/install/x86_64-osx/nightly-2015-06-17/7.10.1/pkgdb/ dump --expand-pkgroot @(stack-0.0.3:System.Process.Read src/System/Process/Read.hs:253:3)
Hello, World!

ravel:test lukeworth$ ~/stack-0.0.3-x86-64-osx/stack --version
Version 0.0.3, Git revision f2454e4f0f82cb31c40424f8a79e55a7a5b8b1a0
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 21, 2015

It looks like what your report says is that: the first time stack build runs, the process fails. But the second time, it looks like it doesn't even try to recompile, and just treats it as a successful build. Is that correct?

I tried going through these steps with the latest version of stack, and did not reproduce the problem. Could you try latest master and let me know whether the problem still exists?

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jun 21, 2015
@krisajenkins
Copy link

@krisajenkins krisajenkins commented Jun 24, 2015

I'm seeing this too. Again, on OSX, and with 0.0.3.0 and the new 0.1.0.0 release. Let me know if there's anything I can do to help track it down.

@krisajenkins
Copy link

@krisajenkins krisajenkins commented Jun 24, 2015

Oddly, making a change to the .cabal file seems to have brought it back to life again. The change was adding a new package, but I'm not sure if was that, or just touching the file that changed things. If it happens again I'll narrow that down...

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 25, 2015

The relevant stack.yaml and .cabal files would be useful. Basically, the closest you can get me to a reproducing test case is what I need to debug this.

@krisajenkins
Copy link

@krisajenkins krisajenkins commented Jun 25, 2015

Okay, this replicates it reliably for me: https://github.com/krisajenkins/stack365

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 25, 2015

That actually makes sense, since the module being changed isn't listed in your .cabal file (it should be under your other-modules). The solution for #105 should address that by not relying on Cabal metadata exclusively.

Can you confirm that adding your module to other-modules fixes the problem?

@krisajenkins
Copy link

@krisajenkins krisajenkins commented Jun 25, 2015

It doesn't really. If I add Message to other-modules, the first call to stack build gives a compiler error as expected. But if I run stack build again immediately (without changing any files) then I get the same no-op behaviour.

It looks like all adding it into other-modules achieved was modifying the cabal file's timestamp...

snoyberg added a commit that referenced this issue Jun 25, 2015
snoyberg added a commit that referenced this issue Jun 25, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 25, 2015

OK, got it. Your case helped isolate this. The problem is that, for executable-only packages, the package was still marked as being installed. I added a step to mark it as not installed before updating the timestamps, which seems to resolve the problem. Can you test out master?

@krisajenkins
Copy link

@krisajenkins krisajenkins commented Jun 25, 2015

Yup, confirmed - that fixes it. (I did have to touch the cabal file first, but after I did that it worked reliably every time.)

Thanks!

@krisajenkins
Copy link

@krisajenkins krisajenkins commented Jun 25, 2015

For the record, that's against 711f2e91715ef77f01e917ca7f61db635911ef1b.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 25, 2015

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.