bazel: Error with external dependencies: some change are not seen

%> bazel version
Build label: 0.2.1-2016-04-08 (@447f7f3)
Build target: bazel-out/local_linux-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Fri Apr 8 17:35:41 2016 (1460136941)
Build timestamp: 1460136941
Build timestamp as int: 1460136941

My project has an external dependency on a tar.gz hosted in s3 (new_http_archive). This dependency has several different build targets that I depend on in one of my packages (runtime dependency, so using the data attribute). I wanted to unify those targets into a single filegroup so that I could depend on them easily in multiple places. In the build file for my external dependency I created a filegroup that lists each of the relevant targets as both srcs and data. When I attempt to build the dependent package I receive an error about the new filegroup not existing:

ERROR: /path/to/workspace/dependent/BUILD:48:1: no such target '@dependency//:system': target 'system' not declared in package '' defined by /path/to/cache/dir/external/dependency/BUILD and referenced by '//dependent:runtime'.

The only way to get rid of this error is to expunge the build tree and rebuild. It seems that the state of the external dependency build targets are not reevaluated if the external dependency has not changed. I believe this to be an error in Bazel’s handling of external dependencies because changes in the build file should be visible to other build targets without first destroying the state of the build tree.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 3
  • Comments: 49 (32 by maintainers)

Commits related to this issue

Most upvoted comments

Sorry for the delay! Thanks for the repro, it is reproducible for me. On first glance, it looks like some sort of bad interaction between new_local_repository and bind(). By changing your example to local_repository, removing the bind(), and copying the BUILD file into the repo I “fixed” the issue, but obviously something is very wrong here. I’ll continue investigating.

Ok, I can reproduce and I have a fix.

Finally got this into a share-able state. To reproduce just check out https://github.com/trainman419/1525 and run the repro.sh script

https://github.com/bazelbuild/bazel/issues/1525#issuecomment-273304683

Thanks! For the record we’ve also reproduced this on bazel 0.4.3

@kchodorow bump. This continues to be a problem for me, and I’ve done my best to provide a reliable test case for it. Can you please at least try the repro and confirm that you can also reproduce this?