Failure to rebuild with stack build/test on change to executable source file (Main.hs)

[rrnewton]

This was a failure not using a released version of stack, but using stack 7412e6b to work on stack itself.

Namely, this travis failure here, was due to stack build and stack test returning successfully, and not rebuilding due to changes in src/main/Main.hs.

Steps to reproduce:

In spite of having the exact commits available above, and running on the same machine I just observed this on (Mac OS laptop). I'm having difficulty reproducing this. What I can say is that before posting this I ran exactly these commands, which are still in my bash scroll back:

$ stack test
<runs fine, normal output>
$ stack build
<nothing>
$ stack clean 
<...>
$ stack build
<same error as in travis build>

Expected output:

I would expect a law that change detection always ensures that stack build; stack clean; stack build does the same thing on the first and second stack builds.

Actual output:

The first stack build and test "succeed" and the newly introduced type error is only detected after cleaning.

Lacking reproduction, I'm hoping someone has a hypothesis as to what may cause failures of update detection in the current architecture.

[rrnewton]

Ok, this seems related to #481 (and its dup #671). Except, #481 says that stack "only" rebuilds when "Main.hs" changes... and this seems to be a case where it didn't EVEN rebuild when Main.hs changed!

So perhaps this is a more basic failure of timestamp/modification handling.

One very important fact that I neglected to mention is that I often run unison -repeat in the background, synchronizing a working copy (including code and .git, but not including .stack-work of course) between a mac laptop and a linux server.

Nevertheless, I was not running this synchronization when the anomalous-seeming bash commands above were run. (But had been previously and the first time the failure occurred.)

[snoyberg]

When you're able to reproduce, I recommend modifying the stack codebase to include information on file timestamps to see if stack sees them as dirty.

[rrnewton]

Will do.

[rrnewton]

Ok, I got it again while using stack to build stack.

What happened just now was that I was continuing to modify Main.hs and stack build was saying there was no work to be done:

$ ./.stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/stack/stack build
TEMP: snap directory is: "/Users/rrnewton/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/"
$

But this was bogus, and I could tell because I'd just disabled that TEMP print message and saved the file. (This time I made absolutely sure I'd saved the file.) Manually cleaning and rebuilding fixed it:

$ stack clean
$ stack build
...
$ ./.stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/stack/stack build
$ 

Which we can see because the last stack call didn't have the debug message.

[snoyberg]

I'm going to be honest: I have no idea what this report means.

[rrnewton]

Sorry, things are a bit self-referential because I'm reporting about problems using stack to build stack.

But the point here was just that I know src/main/Main.hs was modified and saved, and stack build didn't detect the update, thus concluding there was no build work to be done.

As soon as I figure out how to get it to print the timestamps, I'll include the output from that.

[luntain]

Here is a repro. Following can be run as a shell script, preferably in an empty dir:

stack new
echo import Foo > app/Main.hs
echo main = putStrLn foo >> app/Main.hs
echo module Foo where > app/Foo.hs
echo 'foo = "Hello World"' >> app/Foo.hs
stack build
echo garbage >> app/Foo.hs
stack build --dry-run

In the end it says there is nothing to build, while clearly it should report the compilation error in app/Foo.hs

[borsboom]

@luntain What you describe looks like #32.

[luntain]

yes

[snoyberg]

Given that #32 has been resolved with 0.1.3, can you confirm if this issue is also resolved?

[luntain]

OK, it issues a warning about modules not listed in other-modules. It is sad to have to maintain that list though.

[snoyberg]

That's the design of the cabal file format. We could discuss why it's designed that way exactly, but we are stuck with it. Closing as resolved.