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

Surprising lack of recompilation with conditionally defined rules #523

Closed
takano-akio opened this issue Mar 29, 2017 · 4 comments
Closed

Comments

@takano-akio
Copy link
Contributor

I expect the following program to print "update" twice, but it only prints it once with shake HEAD (760dddb). shake-0.15.11 prints "update" twice as expected:

{-# LANGUAGE LambdaCase #-}
import Development.Shake
import Data.Time

data Mode
  = Mode0
  | Mode1

main :: IO ()
main = do
  writeFile "0.in" "foo"
  writeFile "1.in" "foo"
  run $ rules Mode0 -- prints "updated"
  run $ rules Mode1
  writeFile "0.in" "bar"
  run $ rules Mode0 -- does not print "updated"
  where
    run r = do
      putStrLn "Running shake"
      shake shakeOptions
        { shakeChange = ChangeDigest
        --, shakeVerbosity = Diagnostic
        }
        r

rules :: Mode -> Rules ()
rules mode = do
  want ["top"]

  "volatile" %> \f -> do
    alwaysRerun
    writeFile' f . show =<< liftIO getCurrentTime

  case mode of
    Mode0 -> do
      "0.out" %> \f -> do
        need ["volatile"]
        writeFile' f =<< readFile' "0.in"
        liftIO $ putStrLn "updated"
    Mode1 -> do
      "1.out" %> \f -> writeFile' f =<< readFile' "1.in"

  phony "top" $ do
    need $ case mode of
      Mode0 -> ["0.out"]
      Mode1 -> ["1.out"]

I'm not completely sure if this is a bug in shake or I'm just misusing the library, because I don't know under which circumstances rules can be conditionally defined (if at all). However I find the behavior surprising because whenever a rule for "0.out" is defined, it depends on "0.in", so it seems like "0.out" should be rebuilt in the third invocation of shake.

@takano-akio
Copy link
Contributor Author

By the way, this is the same issue as what pacak mentions in #519 (comment) (pacak and I work for the same project).

@ndmitchell
Copy link
Owner

In theory rules shouldn't be conditionally defined, and I think I'll stick with that as the official rule. That said, in your instance, I can't see why Shake should do the new update, and to do it Shake might be doing more work than it needs to - so I think this might be legitimate for people who know what they are doing, and thus it's a Shake bug. I'll continue investigating tomorrow.

@takano-akio
Copy link
Contributor Author

Thank you for your reply. I'll remove conditionally defined rules from our build system.

@ndmitchell
Copy link
Owner

See #524 (comment) for an explanation.

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

No branches or pull requests

2 participants