search

higherkindness / rules_scala

Robust and featureful Bazel rules for Scala
Apache License 2.0
66 stars 28 forks source link

ScalaCheckDeps error with --jobs build option #280

Closed susliko closed 4 years ago

susliko commented 4 years ago

I've noticed that providing the --jobs X, where X is less than 4 (btw I have 4 cores on my machine), results in a build failure on the step of rules_scala_annex compilation with the following message:

INFO: From ScalaCheckDeps external/rules_scala_annex/rules/scala_proto/worker/depscheck_used.success [for host]:
Target '@rules_scala_annex//src/main/scala/higherkindness/rules_scala/common/worker:worker' not used, please remove it from the deps.
You can use the following buildozer command:
buildozer 'remove deps @rules_scala_annex//src/main/scala/higherkindness/rules_scala/common/worker:worker' @rules_scala_annex//rules/scala_proto:worker
ERROR: /home/susliko/.cache/bazel/_bazel_susliko/f6a51c09005d795bf00369ae8a842051/external/rules_scala_annex/rules/scala_proto/BUILD:15:1: output 'external/rules_scala_annex/rules/scala_proto/worker/depscheck_used.success' was not created
ERROR: /home/susliko/.cache/bazel/_bazel_susliko/f6a51c09005d795bf00369ae8a842051/external/rules_scala_annex/rules/scala_proto/BUILD:15:1: not all outputs were created or valid

Do you have any ideas on what might cause such behavior ? :)

SrodriguezO commented 4 years ago

That failure happens when you have unused dependencies on you target definition. You can use the buildozer command it shows to apply the fix :) 

You can use the following buildozer command:
buildozer 'remove deps @rules_scala_annex//src/main/scala/higherkindness/rules_scala/common/worker:worker' @rules_scala_annex//rules/scala_proto:worker

As far as the --jobs count causing issues, I'm not able to reproduce that locally. Could you try applying the buildozer fix and seeing if you're still running into issues?

Edit: see next comment

SrodriguezO commented 4 years ago

Oh wait, it's complaining about deps on rules_scala_annex targets, hadn't notice that.. this is most likely a zinc issue. Can you try deleting your zinc cache and re-building?

susliko commented 4 years ago

Thank you for the fast reply! The thing is I'm not using worker_extra_flag=ScalaCompile=--persistence_dir=.bazel-zinc. So, Zinc stateful compilation seems not to be a problem

SrodriguezO commented 4 years ago

Hmm, could you provide a small reproducible example? I haven't had luck reproducing the issue. Also, can you confirm that things work when you specify --jobs as >= 4?

susliko commented 4 years ago

I am sure, that a totally clean build of my project with --jobs 3 fails for some reason (while succeeds with --job 2 and --jobs 4 :-/), but I haven't managed to reduce it to a minimal reproducible example. It seems that this behavior is observed only in a tricky set of circumstances, which vary for different build-trees and hardware.

Thank you for replies!